PING!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Olivier Dagenais
Software Engineering / Génie logiciel
Formark - Combine the Best of SharePoint® and Livelink®
Phone: 613-599-5173 ext 238
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Make sure you don't miss anything: subscribe to the Formark Newsletter:
http://www.formark.com/support/register/index.asp
> -----Original Message-----
> From: Olivier Dagenais [mailto:olivier.dagenais@formark.com]
> Sent: May 4, 2007 08:57
> To: users@subversion.tigris.org
> Subject: Some observations while branching and merging...
>
> As suggested on the issue tracker page, I'm posting here first to
> discuss my observations and see if they are worth logging as bugs
> and/or enhancement requests. My apologies if this reaches the mailing
> list twice: I sent the first one without being subscribed to the list
> and when I didn't see it in the archives ~12 hours later, I figured I
> needed to subscribe before posting. (the website isn't clear on this)
>
>
> So here's the first scenario. Suppose we have a "test" repository
> with a "bikeshed" folder in it that's totally empty. The user then
> performs the following operations (you can follow along with a console
> transcript, attached as round1.txt):
>
> 1 - Performs a checkout of "bikeshed" (revision 355).
> 2 - Adds a "trunk" folder.
> 3 - Adds a "paint.colour" file.
> 4 - Commits at revision 356.
> 5 - Branches "trunk" to "branch" at revision 356 and adds the
> "brush.type" file.
> 6 - Commits at revision 357.
> 7 - Adds the "roof.composition" file in "trunk".
> 8 - Commits at revision 358.
> 9 - Deletes the "paint.colour" file from the "trunk".
> 10 - Commits at revision 359.
> 11 - Performs a "pull merge" to get the changes from "trunk" into
> their "branch".
> 12 - Commits at revision 360.
> 13 - Performs a "push merge" to have their "branch" be incorporated
> into "trunk".
>
> The following is displayed:
> Skipped missing target: 'bikeshed\trunk\paint.colour'
>
> That file was deleted in the "trunk" and through the "pull" merge in
> step 11 was also deleted in the "branch". Both folders no longer have
> any (visible) record of that file. Should a warning really be issued?
> I would think it shouldn't be, but then again I may have misunderstood
> how I'm supposed to specify the revision ranges when pulling and
> pushing.
>
>
>
> Regardless of the outcome, suppose, for round 2, that instead of
> "paint.colour" being a text file, it was binary. Suppose also that it
> was modified in "trunk" since branching. Here's the simple version of
> the user's operations (and console transcript again attached, as
> round2.txt), on an empty "bikeshed" folder in the "test" repository:
>
> 1 - Performs a checkout of "bikeshed" (revision 375).
> 2 - Adds a "trunk" folder.
> 3 - Adds a "paint.colour" file.
> 4 - Sets the mime type to binary.
> 5 - Commits at revision 376.
> 6 - Branches "trunk" to "branch" at revision 376 and adds the
> "brush.type" file.
> 7 - Commits at revision 377.
> 8 - Adds the "roof.composition" file in "trunk".
> 9 - Commits at revision 378.
> 10 - Modifies the "paint.colour" file from the "trunk".
> 11 - Commits at revision 379.
> 12 - Performs a "pull merge" to get the changes from "trunk" into
> their "branch".
> 13 - Commits at revision 380.
> 14 - Performs a "push merge" to have their "branch" be incorporated
> into "trunk".
>
> The following is displayed:
> C bikeshed\trunk\paint.colour
>
> Is there really a conflict of paint.colour in this case? The "branch"
> obtained the new version through the "pull" merge in step 12 and the
> files in both branches are thus identical! Is this Subversion simply
> being extra careful or did I get my revision ranges wrong when
> merging? If the former, is it necessary to call it a conflict if the
> files are _identical_ in both folders?
>
>
>
> And for round 3, I give you the scenario of the twice-conflicted file.
> Still the "test" repository, this time in the "deli" empty folder,
> here's the user scenario (with transcript in attached round3.txt):
>
> 1 - Performs a checkout of "deli" (revision 385).
> 2 - Adds a "trunk" folder.
> 3 - Adds a "sandwich.txt" file as the pre-conflict version in
> http://svnbook.red-bean.com/nightly/en/svn-
> book.html#svn.tour.cycle.resolve.byhand
> Top piece of bread
> Mayonnaise
> Lettuce
> Tomato
> Provolone
> Creole Mustard
> Bottom piece of bread
> 4 - Commits at revision 386.
> 5 - Branches "trunk" to "branch" at revision 386.
> 6 - Commits at revision 387.
> 7 - Modifies the "trunk" version by adding the lines Sally added after
> "Provolone":
> Sauerkraut
> Grilled Chicken
> 8 - Commits at revision 388.
> 9 - Modifies the "branch" version by adding the lines the other guy
> added after "Provolone":
> Salami
> Mortadella
> Prosciutto
> 10 - Commits at revision 389.
> 11 - Performs a "pull merge" to get the changes from "trunk" into
> their "branch".
> 12 - Fixes the conflict NOT in the same manner as the documentation;
> that is we still remove the "Sauerkraut" inserted in step 7 but we'll
> keep the "Grilled Chicken" between the "Salami" and the "Mortadella".
> 13 - Marks the file/sandwich as resolved.
> 14 - Commits at revision 390.
> 15 - Performs a "push merge" to have their "branch" be incorporated
> into "trunk".
>
> The following is displayed:
> C deli\trunk\sandwich.txt
>
> ...but I just *fixed* the conflict in "branch"! Did I again get my
> revision ranges wrong when merging?? This one is a bit more of a
> problem for us, since we're trying to use branches in place of patches
> and so the "committer" applies "push merges" instead of applying
> patches. When a patch doesn't apply cleanly because of a conflict, a
> committer would normally get the submitter to perform an update first,
> fix anything if necessary and then resubmit. The thing is, there
> doesn't seem to be an equivalent operation the submitter can do here,
> save for performing the "push merge" at their end, resolving the
> conflicts (a second time) and submitting a patch or a copy of the
> resolved file alongside the "push merge" request.
>
>
> Anyway, those are the scenarios we ran into today, except that all
> three showed up in a single "push request"! We're new at this
> intensive branch-and-merge thing, so we're sort of hoping we're simply
> doing something wrong. If not, then hopefully these scenarios will
> help the Subversion developers improve this wonderful software.
>
> And, of course, here's the obligatory version dump:
> 18:19:29 test>svn --version
> svn, version 1.4.3 (r23084)
> compiled Jan 18 2007, 07:47:40
>
> Copyright (C) 2000-2006 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
> This product includes software developed by CollabNet
> (http://www.Collab.Net/).
>
> The following repository access (RA) modules are available:
>
> * ra_dav : Module for accessing a repository via WebDAV (DeltaV)
> protocol.
> - handles 'http' scheme
> - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network
> protocol.
> - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' scheme
>
>
> ...now if you'll excuse me, all this talk about sandwiches has made me
> hungry.
>
> Thanks in advance!
Received on Mon May 14 14:35:58 2007