Hi Andrew,
Thank you very much for the detailed explanation on Merging and
Ancestry. You learn new things every day. :)
After reading your explanation, correct me if I am wrong, I don't think
the current problem is associated with Ancestry. I __don't__ have 2
files with the same name.
I find that __single file merges__ between trunk and branches succeed if
the file already exists (ie update) but **fails** if the file is new (ie
added in branch and needs to be merged into trunk).
For __single file merges__ to succeed when adding a new file, we need to
merge at directory level. I also understand that it needs to be done at
the directory level because the directory controls need to be updated
etc. etc.
My question is, shouldn't the directory controls be updated when it
detects an "Add" during single file merges (the directory already
exists) just as the directory control gets updated during a single file
merge of an existing file.
Your thought and feedback is much appreciated.
Thanks
Lakshman
> -----Original Message-----
> From: Reedick, Andrew [mailto:Andrew.Reedick@bellsouth.com]
> Sent: Saturday, 30 September 2006 12:52 AM
> To: Lakshman Srilakshmanan; users@subversion.tigris.org
> Subject: RE: Bug/Inconsistency in merging single files
>
>
>
> > -----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 Mon Oct 2 03:28:50 2006