Bug in documentation or in Subverison 1.5?

[Sohail Somani <so...@taggedtype.net>]

Hi,

I was just reading through the updated documentation for the new merge 
tracking. It all looks very good and I wish I could document as well as 
the authors of the book!

In the chapter on merging (http://tinyurl.com/3ay7b3), the documentation 
states:

"When merging your branch back to the trunk, however, the underlying 
mathematics is quite different. Your feature branch is now a mish-mosh of 
both duplicated trunk changes and private branch changes, so there's no 
simple contiguous range of revisions to copy over. By specifying the --
reintegrate option, you're asking Subversion to carefully replicate only  
those changes unique to your branch. (And in fact it does this by 
comparing the latest trunk tree with the latest branch tree: the 
resulting difference is exactly your branch changes!)"

I hope Subversion isn't actually using latest trunk with latest branch 
because this causes race conditions. Say I do svn merge on my branch and 
svn commit to create revision N. For simplicity, assume that the last 
version of trunk committed was N-1.

Now when I svn switch to trunk and execute svn merge --reintegrate ..., 
according to the documentation, svn would pretty much do something like:

svn merge $URL/trunk:HEAD $URL/branch:HEAD

Which is equivalent to:

svn merge $URL/trunk@N-1 $URL/branch/@N

However, if someone checks into trunk just before you execute the 
command, you will revert their changes:

svn merge $URL/trunk@N+1 $URL/branch/@N

I'm hoping what the documentation actually meant to say is that svn merge 
would use the last revision merged from trunk into branch as the base of 
the comparison and *not* the latest trunk.

-- 
Sohail Somani
http://uint32t.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org