On Feb 10, 2006, at 9:53 PM, Blair Zajac wrote:
> On Feb 10, 2006, at 6:21 PM, Matt England wrote:
>> The consequences don't (yet) appear to be as bad as I thought in
>> this scenario (play back the email thread for more info). A
>> "merge" doesn't happen, but the system still identified a conflict
>> file, it just doesn't diff/merge it very well...and I can probably
>> deal with that, for I don't think I have that many files that were
>> edited in both my trunk and branch.
>> Example below of a trunk-branch comparison that both had their
>> folders renamed to the same thing and then only one (of the four)
>> files were changed (new-file.txt). The system doens't really
>> merge the one changed file very well (because it doesn't keep
>> track of which files are the same, it just shows the entire file
>> as different)...but at least it identifies which ones were changed
>> and which ones wheren't...simply because the merged-in files are
>> overwritten on top of the ones in trunk and don't show up on 'svn
>> status' if they weren't changed. I can use a merge tool or just
>> manage it by hand for all the conflicted files...I hope.
>> Maybe this was obvious to everybody else...but it wasn't to me.
>> Hopefully this will go as well as I hope right now. We'll see.
> Hi Matt,
> In your case, what I recommend doing is the following. This should
> avoid the use of third party merge tools and be pretty efficient in
One more thing to mention.
Check out the svnmerge.py tool to automatically keep track of
revisions already merged from one location to another. It makes life
very easy and reduces the chances of problems.
The version in trunk is newer than in 1.3.0:
Mailing list to discuss feature, development and such is at
but feel free to discuss it on svn-users.
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
Subversion training, consulting and support
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Feb 11 07:03:43 2006