[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Bug/Inconsistency in merging single files

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-09-29 16:52:19 CEST

 

> -----Original Message-----
> From: Lakshman Srilakshmanan
> [mailto:lakshman.srilakshmanan@tradingpost.com.au]
> Sent: Thursday, September 28, 2006 2:16 AM
> To: users@subversion.tigris.org
> Subject: Bug/Inconsistency in merging single files
>
> Hi All,
>
> This is a problem discussed in this forum 6 weeks ago. I have now done
> further investigation and would like to present my findings. Old email
> trail can be found at
> http://www.nabble.com/Merging-and-Ancestry-tf2120346.html#a5919783
>
>
> In summary I find that single file merges work for updates
> but **fails**
> for add/delete.
>
> Is this a bug or expected behaviour. If it was designed this
> way, could
> someone please tell me the rational behind it.
>
>

Merges in any version control system normally require two passes. The
first pass merges the directory, which will add or remove file objects.
The second pass merges the actual file contents. So you need to merge
the directory non-recursively, revert the other files in the dir, and
then merge the single file.

You can see the two passes when dealing with 'Evil Twins'. 'svn merge'
will list files as being A'dded or D'eleted, whereas 'svn status' will
list the exact same files as being U'pdated or C'onflicted. Ex:

1. Create a branch
        svn copy trunk branch

2. Create a pair of evil twins:
        svn add branch/foo.java
        svn add trunk/foo.java
    Evil Twins have the same name, but different histories, version
trees, etc., because they were each created with 'svn add' instead of
'svn copy'. Let's pretend that the branch/foo.java has 5 revisions, and
that the trunk/foo.java has 10 revisions.

3. Note the output of 'svn merge'
        svn merge -r 218:219 svn://server/test/trunk/test2/branch
        A foo.java
    The file was Added in the directory merge pass. This means that the
branch's foo.java (with 5 revisions) replaces the trunk's foo.java
(which as 10 revisions.) Behind the scenes trunk/foo.java was deleted,
and branch/foo.java was 'svn copy'ed to trunk/., hence the 'A
foo.java'.

4. However, 'svn status' tells us that in the second pass (the merging
of the files' contents) that there is a merge conflict.
        svn status
        ? foo.java.working
        ? foo.java.merge-right.r219
        ? foo.java.merge-left.r0
        C foo.java

So trunk/foo.java now has 6 revisions (5 plus the merge revision)
instead of the original 10.

By comparison, in ClearCase, you have to explicitly merge directories
because directories are first class objects just like files are. You
would run the directory merge repeatedly until there were no items to
merge. (A dir merge could add a new directory, so a second merge would
be needed to merge the newly merged directory, ad infinitum.) Then you
would run a merge to merge just the files.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 29 16:53:20 2006

This is an archived mail posted to the Subversion Users mailing list.