Strategies for push/merge problem?

[Taavi Burns]

On Fri, Jan 9, 2009 at 8:00 AM, Martin Geisler <mg at daimi.au.dk> wrote:
> I expected Subversion to work like that too, but it turns out to be
> false. Here I commit revision 2 without having updated to revision 1:

I think this is a misleading statement.  Subversion doesn't require a
working copy to be at a single revision; it versions things per-thing.
 Subversion's internal storage has this idea of a series of revisions,
where each one refers to the entire state of a whole repo.  But pretty
much anything else seems more closely based on diffs and patches.  A
commit is simply generating a diff between the
versions-you-had-checked-out-of-each-element and
version-that-is-now-in-your-working-copy and attempting to apply it to
the server's most recent revision.  "Trivial" merges (disjunct files)
are handled "by the server" only insofar as Subversion is completely
ignorant of their effects.

That's my take at least, having had to use it for a year at work.  I
also think it sucks.  :)

By examples, note the per-file revision numbers returned by 'svn info':

...
$ svn commit -m "added file2"
Adding         file2.txt
Transmitting file data .
Committed revision 2.
$ svn info *
Path: file1.txt
Name: file1.txt
URL: file:///tmp/svnrepo/file1.txt
Repository Root: file:///tmp/svnrepo
Repository UUID: 030991e8-8b2b-4e04-b511-df11e5cfbb91
Revision: 1
Node Kind: file
Schedule: normal
Last Changed Author: taavi
Last Changed Rev: 1
Last Changed Date: 2009-01-09 13:23:37 -0500 (Fri, 09 Jan 2009)
Text Last Updated: 2009-01-09 13:23:29 -0500 (Fri, 09 Jan 2009)
Checksum: d3b07384d113edec49eaa6238ad5ff00

Path: file2.txt
Name: file2.txt
URL: file:///tmp/svnrepo/file2.txt
Repository Root: file:///tmp/svnrepo
Repository UUID: 030991e8-8b2b-4e04-b511-df11e5cfbb91
Revision: 2
Node Kind: file
Schedule: normal
Last Changed Author: taavi
Last Changed Rev: 2
Last Changed Date: 2009-01-09 13:24:18 -0500 (Fri, 09 Jan 2009)
Text Last Updated: 2009-01-09 13:24:09 -0500 (Fri, 09 Jan 2009)
Checksum: c157a79031e1c40f85931829bc5fc552

=====================================

And if we update a file on the server and then try to commit
additional local changes:
$ cd ../wc2
$ svn up
A    file2.txt
A    file1.txt
Updated to revision 2.
$ echo baz >> file2.txt
$ svn commit -m "updated file2"
Sending        file2.txt
Transmitting file data .
Committed revision 3.
$ cd ../wc1
$ echo bazzy >> file2.txt
$ svn commit -m "updated file2 again"
Sending        file2.txt
svn: Commit failed (details follow):
svn: Out of date: 'file2.txt' in transaction '3-1'
========================================

In that particular case, the two changes should cause a merge
conflict, BUT that's not why svn refused to commit: it refused because
the working copy of that particular file was out of date, regardless
of what changes you wanted to commit.

-- 
taa
/*eof*/