Matt,
> -----Original Message-----
> From: Matt England [mailto:mengland@mengland.net]
> Sent: vrijdag 10 februari 2006 20:28
> To: Lieven Govaerts; Ryan Schmidt
> Cc: Matthew England; SVN Users email list
> Subject: Re: Can a merge follow changes in paths in trunk/branch?
>
...
>
> So it appears that, at least in this context, a merge is not
> a recursive diff. Is this a correct statement? In this same
> thought: it's probably obvious that I'm still very unfamiliar
> about what subversion *is* and *is
in fact, a merge really is like a recursive diff of files and folders.
However, while a diff only contains content-changes ( binary or text delta's
), a merge will also contain name changes, adding files and folders etc. So
if you add a folder and move a file to that folder in your branch, and later
merge that changeset to your unchanged(*) trunk, svn merge will create that
folder and move that file in trunk as well.
> not* doing with respect to merges (and I realize the Lieven
> and Ryan and possibly others are trying to tell me...and the
> info is trying to seep through into my brain). I hear that
> that there is no merge tracking...but that there is a lot of
> special things that merge does from diff. I'm finding myself
> thoroughly confused, in part because I don't yet understand
> why some merge intelligence would be put in without "all" the
> intelligence, but I suspect I will learn more about this if I
> choose to continue to study it (which might be hard to find
> time to do at this point).
Well, merging branches is a complex scenario with a lot of possible
situations and bordercases. The devs have already brought Subversion where
it is now, but that doesn't mean they're finished.
> --------------------------------------
> The much-bigger question:
> --------------------------------------
>
> What, if anything, can we do to merge our branches? Are we
> going to have to through and do diffs by hand...or something
> extremely manual? We may be in a really bad place, and I'm
> trying to see what we can do to get around this problem.
My advice would be to think before you do, meaning:
- your team is doing parallel development with a tool they're clearly not
yet familiar with. Maybe you should refrain from par. dev. for a while so
you can come up to speed with Subversion? I'm not saying you should stop
working on more than one branch, but maybe limit your refactoring work on
one branch, and merge that refactoring to other branches when ready.
- organize your branches in a structured way and document that! Really, if
you're doing parallel development you really should be aware of what types
of branches you're going to create, what type of changes are allowed on
those branches etc.
I can strongely advise you to read the "Streamed Lines: Branching Patterns
for Parallel Software Development" articles at CMCrossroads.com, it's not
Subversion specific, but combine those articles with the Subversion book and
you have all the knowledge a SVN admin should have. ( well not all, but you
get the point ).
Direct link: http://www.cmcrossroads.com/bradapp/acme/branching/
And then learn, take the time to test certain behaviour that's not clear to
you and ask help if needed, but you're already doing that :)
> I'm going to be dreaming up some potential work arounds and
> trying them in a test repo. Any suggestions are appreciated.
>
> I'm hoping I can at least get around this by making all the
> directory and file-path structures the same and then using a
> standard unix patch command and apply the patch output to the
> trunk. Does that make sense?
>
> Also, it's important to note that I goofed up my scenario
> example above. This is what we actually did:
>
> svn copy trunk/ branch/
> branch/folder/test.txt modified
> trunk/folder/test.txt modified
> trunk/folder/test.txt -- moved to -->
> trunk/newfolder/test.txt branch/folder/test.txt modified (in
> addition to above modification) trunk/newfolder/test.txt
> modified (in addition to above modification) # Right now the
> trunk and the branch won't merge, # presumably because they
> have a different directory layout (??)...
> # ...so we try making the same directory layout...
> branch/folder/test.txt -- moved to -->
> branch/newfolder/test.txt cd trunk/ # so that now both trunk/
> and branch/ now have the same dir structure, # but apparently
> that doesn't work, either, for some reason I don't yet #
> understand, but I'm still a young grasshopper wrt svn merge wisdom.
> svn merge -r M:N ../branch
Or you could revert the revision in which you moved trunk/folder to
trunk/newfolder, then do the merge ( you may get a conflict on test.txt if
you both made changes on the same lines in the file ), and then reapply the
above revision?
> In summary, we were re-orging the dir structure in the trunk
> (one of my developers got a bit too ambitious with a reorg
> without considering the implications of an outstanding
> branch) before merging in changes we had in a significant branch.
Do not allow parallel branches to diverge this far, split refactorings in
smaller parts and merge ( or commit ) them when ready. This makes it easier
to work with Subversion, but also keeps your code more stable because these
large changes are tested in small parts.
> I'm not sure if this fact changes the nature of the problem
> and possible solutions, but I thought it worth mentioning.
>
> Ryan and Lieven- I very much appreciate your help. If you
> are interested, I would be happy to pay either of you
> directly (say, via paypal.com) if you'd be interested in
> providing me some direct-and-interactive support, in hopes
> that it can save you time of having to read and reply to my
> lengthy emails...as well as hopefully make you a few bucks.
> -Matt
I already have a full time job supporting Subversion ( amongst other things
I do there ). In my spare time I try to give something back to the svn
community, so just keep sending those long mails, I or someone else here
will answer them. BTW, if your company seeks professional support for
Subversion, maybe you should consider to contact CollabNet:
http://www.collab.net/subversion/.
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 10 22:15:12 2006