Merge on push?

[Giorgos Keramidas]

On Tue, 10 Jun 2008 10:43:32 +0200, Roman Kennke <roman.kennke at aicas.com> wrote:
>>>> Yes, this is exactly the same with Subversion -- you cannot do a
>>>> commit unless you have an up-to-date SVN checkout. With SVN you must
>>>> do a 'svn update' to bring your checkout up-to-date, and this actually
>>>> does a merge for you.
>>>
>>> Aha, interesting. Haven't used Subversion enough to know that. I was
>>> assuming that it behaves more or less like CVS here. Good point for
>>> argumentation.
>>
>> SVN is behaving exactly like CVS in this case.
>
> Now I'm confused. You beat me to installing SVN myself and try for
> real.  I know that CVS allows commits on a non-up-to-date checkout, as
> long as this commit doesn't touch any files that have changed in the
> repository.

Exactly.  If a file has changed in the repository CVS will stop you from
committing, and warn that:

cvs commit: Up-to-date check failed for `foo'
cvs [commit aborted]: correct above errors first!

Subversion works exactly like this too.

> I was assuming that SVN behaves similar, but was told that SVN behaves
> more like HG, in that it only allows commits on up-to-date checkouts,
> regardless of the files that are touched by the commit. So what is it
> now?

No t really, no.  You can still commit files in Subversion with a `mixed
version' workspace.  Try this out, by creating a `clean' repository and
doing something like:

  $ mkdir -p /tmp/svnroot /tmp/work
  $ svnadmin create /tmp/svnroot
  $ cd /tmp/work
  $ svn co file:///tmp/svnroot root
  $ cd root
  $ echo foo > foo ; echo bar > bar
  $ svn add foo bar
  $ svn ci -m 'add foo and bar'

At this point `foo' and `bar' should be of the same revision.  Update
your workspace

  $ svn up

and then commit a change only to `foo' with:

  $ echo foo changed > foo
  $ svn ci -m 'changed foo'

Now update only `foo' to the latest revision, and modify `bar':

  $ svn up foo

Your working directory is now a `mixed revision' tree, and you can see
this with `svn stat':

  $ svn stat -v
                1        1 keramida     .
                2        2 keramida     foo
                1        1 keramida     bar

The two revision numbers of `foo' and `bar' are different because `bar'
hasn't been affected by the last change to `foo'.  But you can still
commit to the file, without problems:

  $ echo change bar > bar
  $ svn ci -m 'change bar' bar
  Sending        bar
  Transmitting file data .
  Committed revision 3.

The last change was committed with a `bar' file from revision 1, but the
file wasn't affected in the repository from any later version, so SVN
is smart enough to let you commit a new change.