Re: Maintaining branches...
--- Paul Sander [EMAIL PROTECTED] wrote: Just a couple of brief comments... --- Forwarded mail from [EMAIL PROTECTED] cvs update command: * -A would have to check for locally stored merge info for the file and remove it before updating Note that -r should do the same. * without options, same as co without options * without options, cvs update on a merged working copy needs to update the merge info in the working dir's CVS subdirectory for the file. * -j would have to record merge info locally, also would have to deal with multiple -j calls on the same file. Accually (it was brought to my attention) that the -A option should update local merge info. So, the -A and -r options should account for the merge that -A or -r performed. Using merge math as this thread was disscussing, that resultant merge may negate the merge, in that case the local merge info would be removed. Mark __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Off list comment (was: Re: Maintaining branches...)
Sorry to bring this up here, however, someone recently sent me an off list question regarding this particular message I had posted. Unfortunately, I fat fingered it and deleted the message. :- If the person is still interested, feel free to contact me again. Apologies, mrc On Thu, Jun 14, 2001 at 02:44:52PM -0700, Mike Castle wrote: On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote: Mike Castle wrote: But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. I'm going to pretend these are valid branch version numbers for the sake of argument. Thanks. Been a while since I've actually branched with CVS (stuck using perforce at work now). And since I never really pay attention to them, I always forget the numbering sequence it uses. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch I thought the idea here was that you could say merge branch 1.1.0 and CVS would say, you already merged change A on DATE - (s)kip this portion or (r)emerge? Sorry. I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5, apply patch was a matter of implementation, not presentation. If the user chose skip, then I'd imagine it'd work like that. I assume the remerge stuff would come from when cvs determining what it needs to apply, rather than actually at application time. Patch, for instance, determines it at application time. What about merging back and forth. User makes change 1.1-1.2, and merges it onto branch, then it gets merged back. Users would normally expect cvs to track that information and act accordingly (ie, not present any conflicts based upon that particular bit). But, since you could have +X amount of changes between the up -j and the commit, you really can't do that. There will be conflicts. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
--- Forwarded mail from [EMAIL PROTECTED] On Thu, Jun 14, 2001 at 10:15:16PM -0700, Paul Sander wrote: Your first case is really two merges, one requiring the user to supply version 1.1.0.3 as the common contributor. The other is a single join with version 1.1.0.2. You could also do this: version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 ) And then resolve the inevitable conflicts resulting from the first bug-fix merge. This is how CVS currently works. Two points: If I do that manually, I can easily avoid having to deal with a conflict by doing it in multiple stages. When I want to merge all the things in, I merge in the diff from 1.1 - 1.1.0.2. Then I apply the diff from 1.1.0.3 - current. Because I know I've already applied 1.1.0.3. If you're going to automate this, this is how I would expect the automation to work. If I understand you correctly, what you want is this: Merge 1: specification - version 1.4 = 1.3 + ( 1.1.0.3 - 1.1.0.2 ) result - version 1.4 = 1.3 + ( 1.1.0.3 - 1.1.0.2 ) Merge 2: specification - version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 ) result - version 1.5 = 1.4 + ( 1.1.0.5 - 1.1.0.3 ) + ( 1.1.0.2 - 1.1 ) Is this correct? What about the case where the first merge is a partial, where the result (version 1.5) contains only a subset of the deltas between 1.1.0.3 and 1.1.0.2? In this case, applying all of (1.1.0.5 - 1.1) to 1.4 and resolving conflicts seems like the right thing to do. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
I have been watching this thread with some interest. Modifying CVS to record (with intergity) and use recorded merge information might require much code work in cvs. (Not to say that it wouldn't be great to have the functionality, or that I have ever seriously looked at the source). Whether it can be done with RCS new phases or something similar to editors/watchers (the permanent) location), there would be things commands would need to do. First, it might be necessary to store merge info temporarily in the working CVS subdirectory first, then promote the files' merge info to the permanent location on commit of the files. cvs co command: * without options, would have to check to make sure locally stored merge info for a file being checked out doesn't exist, if it does (a unix rm on the working file has been perform and is being replaced) it should discard the merge info for that file. * -j would have to record merge info locally cvs update command: * -A would have to check for locally stored merge info for the file and remove it before updating * without options, same as co without options * without options, cvs update on a merged working copy needs to update the merge info in the working dir's CVS subdirectory for the file. * -j would have to record merge info locally, also would have to deal with multiple -j calls on the same file. cvs commit command: * this should move merge info from the working dir CVS subdirectory to the permanent location (RCSfile, CVS subdir in repository) and clear the local merge info in the CVS subdir. The above might be mandatory for a first release to track merges, I am sure there are more changes that might be needed. Then there's the changes to commands to use the merge information. Commands like: cvs status command: cvs log command: cvs history command: Maybe new commands: cvs findmerge -rbranch tag I don't know what it would take to at least get cvs track merging in a robust way. This is all some thoughts I'd wanted to share. Mark __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Wed, Jun 13, 2001 at 11:12:16PM -0700, Paul Sander wrote: Is there some reason why the -j's could not be recorded in the CVS directory, and corrected with each update? The joins shouldn't be recorded in the repository until the commits are done anyway. -j makes a notation in the CVS directory (or appends an existing one if multiple joins are done between commits), and -r and -A clear out the notations. At commit time, the notations could be recorded in the RCS files for future use. When a file is in this merged-but-not-committed state, rm foo; cvs up foo should do one of two things: - erase the -j notation, or - redo the merge(s) Redoing the merge would basically make -j sticky -- but only a little sticky, like a PostIt Note :-) -- since it should become unstuck after a commit. The former would preserve consistency with current behaviour; the latter would bring this case more into line with the rest of CVS. Which of these would be preferable? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
[ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ] Subject: Re: Maintaining branches... Is there some reason why the -j's could not be recorded in the CVS directory, and corrected with each update? That's an intersting idea. It would certainly help me remember what I'm going in a given working directory, if nothing else! The joins shouldn't be recorded in the repository until the commits are done anyway. That's true! -j makes a notation in the CVS directory (or appends an existing one if multiple joins are done between commits), and -r and -A clear out the notations. At commit time, the notations could be recorded in the RCS files for future use. That's the trick. How do you do that without impacting RCS compatability??? Is doing it as part of the commit message sufficient? -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 03:26:31PM -0400, Derek R. Price wrote: Mike Castle wrote: And I think that this complete merging happens less than you might think. It cannot handle the situation where a specific set of changes is migrated before another (i.e., -j tag1 -j tag2). It may not even be off of an immediate branch, but rather a couple over. What can't it handle about this and why? Originally I was thinking only highwater marks. But I guess something like a .newsrc style range/set would work. (Ok, what IS that data structure properly called?) But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. 1.1.0.3 is made, and that particular change is needed immediately on the branch branch, so only it is moved over. So 1.2 == 1.1 + 1.1.0.3. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Maintaining branches...
-Original Message- From: Ralph Mack [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 10:52 PM To: [EMAIL PROTECTED] Subject: Re: Maintaining branches... [Quoth I... :-)] 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. As I lay in bed thinking about all this, it suddenly occurred to me that, since CVS is always using the root as its reference version, CVS (and its ancestor RCS) can get away with not recalculating any diffs at all during an update but merely selecting from among the diffs calculated during prior commits. This is a significant time savings. A commit becomes the only operation that actually calculates a diff as a side-effect. CVS does not always use the root as its reference version. The restriction is not that CVS does not permit merging, but that it does not itself have an automatic way of keeping track of what has been merged where. The user can keep track of this information with a tag, or externally, or can just merge the last change (which is usually what you want to do anyway). A commit is not the only operation to create a diff; the cvs diff command will normally also do so (although that diff is not kept by CVS; if you want to keep it as a diff you can save it yourself). For example, cvs diff -r 1.10.2.6 -r 1.12.6.3 foo.C will create a diff between the version of foo.C in two different branches. (If you like, cvs update -r 1.23.2.3 foo.C; cvs update -j 1.10.2.6 -j 1.12.6.3 foo.C will attempt to apply the difference between 1.10.2.6 and 1.12.6.3 to 1.23.2.3, which is usually not a useful thing to do.) Is this true? If so, it seriously restricts the kind of merge behavior that CVS can support, but I can see why it was done. Lots of other things about CVS that seemed a little odd also suddenly become comprehensible. It restricts the kind of merge behavior that can be done without further ado and record-keeping. It does not restrict the ability to arbitrarily merge if the user is willing to keep track of things in some way. We use a tag to show what has been merged already. How hard is it to extract three different revisions of the same file to a temp area outside of the normal checkout tree using CVS? If I were going to do that, I'd do three separate cvs update -r ... commands, moving each to the appropriate directory after the update. Again, it is not something that CVS automatically does with a simple command out of the box. (I'm contemplating what a seperate graphical merge utility layered on CVS might need to do.) If I were to use this approach in order to use a different merge I would write a script to do it. There is certainly no reason why it can't be done, but for most purposes CVS's merging is quite adequate. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
Mike Castle wrote: On Thu, Jun 14, 2001 at 03:26:31PM -0400, Derek R. Price wrote: Mike Castle wrote: And I think that this complete merging happens less than you might think. It cannot handle the situation where a specific set of changes is migrated before another (i.e., -j tag1 -j tag2). It may not even be off of an immediate branch, but rather a couple over. What can't it handle about this and why? Originally I was thinking only highwater marks. But I guess something like a .newsrc style range/set would work. (Ok, what IS that data structure properly called?) But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. I'm going to pretend these are valid branch version numbers for the sake of argument. 1.1.0.3 is made, and that particular change is needed immediately on the branch branch, so only it is moved over. So 1.2 == 1.1 + 1.1.0.3. I'd probably call this 1.1 + 1.1.0.2-1.1.0.3. And it would really mean 1.1 + 1.1.0.2-1.1.0.3 + X, where X is some arbitrary set of changes (possibly null, possibly including conflict resolution). Assuming the ancestor won't always provide all the needed information. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch I thought the idea here was that you could say merge branch 1.1.0 and CVS would say, you already merged change A on DATE - (s)kip this portion or (r)emerge? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- I will not bring sheep to class. I will not bring sheep to class. I will not bring sheep to class... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote: Mike Castle wrote: But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. I'm going to pretend these are valid branch version numbers for the sake of argument. Thanks. Been a while since I've actually branched with CVS (stuck using perforce at work now). And since I never really pay attention to them, I always forget the numbering sequence it uses. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch I thought the idea here was that you could say merge branch 1.1.0 and CVS would say, you already merged change A on DATE - (s)kip this portion or (r)emerge? Sorry. I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5, apply patch was a matter of implementation, not presentation. If the user chose skip, then I'd imagine it'd work like that. I assume the remerge stuff would come from when cvs determining what it needs to apply, rather than actually at application time. Patch, for instance, determines it at application time. What about merging back and forth. User makes change 1.1-1.2, and merges it onto branch, then it gets merged back. Users would normally expect cvs to track that information and act accordingly (ie, not present any conflicts based upon that particular bit). But, since you could have +X amount of changes between the up -j and the commit, you really can't do that. There will be conflicts. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
--- Forwarded mail from [EMAIL PROTECTED] [ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ] Subject: Re: Maintaining branches... Is there some reason why the -j's could not be recorded in the CVS directory, and corrected with each update? That's an intersting idea. It would certainly help me remember what I'm going in a given working directory, if nothing else! The joins shouldn't be recorded in the repository until the commits are done anyway. That's true! -j makes a notation in the CVS directory (or appends an existing one if multiple joins are done between commits), and -r and -A clear out the notations. At commit time, the notations could be recorded in the RCS files for future use. That's the trick. How do you do that without impacting RCS compatability??? Is doing it as part of the commit message sufficient? RCS has a standard method for extending the content of the RCS files, called the newphrase. (See the rcsfile(5) man page.) These things have both file-wide and version-wide scopes, and RCS ignores the ones it doesn't recognize. There should be no problem adding one or two newphrases to track merges. It might also be worthwhile to lobby the RCS developers (Paul Eggert?) to add a command line argument to the ci program to set such a paramter, and maybe also add arguments to the RCS program to add, query, and remove newphrases. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
--- Forwarded mail from [EMAIL PROTECTED] On Thu, Jun 14, 2001 at 04:48:33PM -0700, Paul Sander wrote: --- Forwarded mail from [EMAIL PROTECTED] But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. 1.1.0.3 is made, and that particular change is needed immediately on the branch branch, so only it is moved over. So 1.2 == 1.1 + 1.1.0.3. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. I believe the desired behavior really is this: First merge: version 1.2 = version 1.1 + ( version 1.1.0.3 - version 1.1 ) Second merge: version 1.3 = version 1.2 + ( version 1.1.0.5 - version 1.1.0.3) Is this correct? That's what I thought at first, but now I believe he really does mean: First merge: version 1.2 = 1.1 + (1.1.0.3 - 1.1.0.2) commit trunk-only revs 1.3 and 1.4 Second merge: version 1.5 = 1.4 + (1.1.0.2 - 1.1) + (1.1.0.5 - 1.1.0.3) = 1.1 + (1.4 - 1.2 [sic]) + ( 1.1.0.5 - 1.1) And even if he doesn't mean that, it's a case that seems worth discussing. Say you have the familiar situation of Release-2 development on the trunk, and a Post-Release-1 bug-fix branch B. Someone fixes a bug on B. Then, before the team is ready to cope with a wholesale merge, it's discovered that that particular bug is a showstopper for continued trunk development. So you want to merge that bug fix only, but keep the rest of the fixes on B isolated until a later date. Your first case is really two merges, one requiring the user to supply version 1.1.0.3 as the common contributor. The other is a single join with version 1.1.0.2. You could also do this: version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 ) And then resolve the inevitable conflicts resulting from the first bug-fix merge. This is how CVS currently works. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 10:15:16PM -0700, Paul Sander wrote: Your first case is really two merges, one requiring the user to supply version 1.1.0.3 as the common contributor. The other is a single join with version 1.1.0.2. You could also do this: version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 ) And then resolve the inevitable conflicts resulting from the first bug-fix merge. This is how CVS currently works. Two points: If I do that manually, I can easily avoid having to deal with a conflict by doing it in multiple stages. When I want to merge all the things in, I merge in the diff from 1.1 - 1.1.0.2. Then I apply the diff from 1.1.0.3 - current. Because I know I've already applied 1.1.0.3. If you're going to automate this, this is how I would expect the automation to work. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
[Quoth Stephen Cameron...] There is no merge history. OUCH! That should probably be mentioned when people are comparing CVS to things like ClearCase. Merge history is an important feature. In ClearCase, you can get a version tree for each file showing every branch and merge that ever occurred, which I have found essential when trying to figure out precisely what happened. Knowing the merge history also enables the findmerge tool to know the best reference version to use for merges, which generally keeps merges very small. I am a little puzzled that people aren't having more problems with merges in CVS. When there is pipelined development going on, it seems inevitable that you are going to be copying changes across at least three versions of a product on a relatively frequent basis. Do CVS developers really do all these parallel updates by hand-editing with cut/paste? Maybe the term merge is ambiguous. My concept of a merge is: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. Does CVS use a different merge concept entirely? Assuming that the answer is no, how much of this is user-accessible? Does CVS support a command to do a merge of two revisions of a single file from a user-specified reference revision? This is the fundamental user-controlled merge operation. From your comments, it sounded like the answer is no, that it always merges from the root of the oldest branch or some such thing. I would like to see CVS support, at least for individual files, a means to specify the from, to, and reference revisions on an update. CVS could generalize this to directories and trees by permitting the user to specify branches or labels for from and to and a label for the reference revision. With this support, everything else (e.g. labeling important merge points) could then be done through customary disciplines, like always label after checking in a merge, possibly supported through scripts. This approach seems to be in harmony with the CVS philosophy of providing the raw mechanics without dictating how they are to be used. Did I miss something? Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Wed, Jun 13, 2001 at 10:25:18PM -0400, Ralph Mack wrote: Maybe the term merge is ambiguous. My concept of a merge is: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. Does CVS use a different merge concept entirely? Not quite, but close: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. apply the diff, as a patch, to the to version They don't even have to have a common ancestor. It can be any two versions, and really, in any order (example, maybe you want to back out a specific set of changes on a particular branch). mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
[Quoth I... :-)] 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. As I lay in bed thinking about all this, it suddenly occurred to me that, since CVS is always using the root as its reference version, CVS (and its ancestor RCS) can get away with not recalculating any diffs at all during an update but merely selecting from among the diffs calculated during prior commits. This is a significant time savings. A commit becomes the only operation that actually calculates a diff as a side-effect. Is this true? If so, it seriously restricts the kind of merge behavior that CVS can support, but I can see why it was done. Lots of other things about CVS that seemed a little odd also suddenly become comprehensible. How hard is it to extract three different revisions of the same file to a temp area outside of the normal checkout tree using CVS? (I'm contemplating what a seperate graphical merge utility layered on CVS might need to do.) This approach would be slow, of course, as it would have to extract and diff twice for every file in the covered area to determine if there is any work to do for each one. The result of the merge would be copied back to the checkout tree. By the way - step 4 should have read apply the result to the reference version (not the to version). I'm going back to bed. :-) Ralph A. Mack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
This is all true. The from version is usually specified by the user with a -j option. The to version is the one in the user's workspace. The reference version can be given with a second -j option, but by default it's the version at the intersection of the branches that include the from and to versions. One of the annoying results of this is that when the same two versions are merged several times, the results of prior merges show up as merge conflicts when the default reference version is used. The workaround is to commit the results of each merge and apply a label just to identify it as the reference for the next merge. If CVS had and equivalent to ClearCase' merge arrows, then a more intelligent choice could be made for the reference version, reducing the distances of the diffs and eliminating the needless conflicts. --- Forwarded mail from [EMAIL PROTECTED] On Wed, Jun 13, 2001 at 10:25:18PM -0400, Ralph Mack wrote: Maybe the term merge is ambiguous. My concept of a merge is: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. Does CVS use a different merge concept entirely? Not quite, but close: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. apply the diff, as a patch, to the to version They don't even have to have a common ancestor. It can be any two versions, and really, in any order (example, maybe you want to back out a specific set of changes on a particular branch). --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Wed, Jun 13, 2001 at 09:00:09PM -0700, Paul Sander wrote: If CVS had and equivalent to ClearCase' merge arrows, then a more intelligent choice could be made for the reference version, reducing the distances of the diffs and eliminating the needless conflicts. Of course, that's nearly impossible to do within CVS. cvs up -j change change change change cvs up change change change cvs up cvs commit compare to cvs up -j change change chang echange oop... don't like that find . -name '*.[ch]' | xargs rm cvs up change change change cvs up cvs commit Which is merged? which isn't? There would probably have to be an extra lot of special casing to handle the fact that this file had had a -j done onto it, but not yet committed. And if it had been deleted and updated, mark that -j as undone. Plus, let's say you do the following: cvs up -r branch cvs tag tag1 cvs up -A cvs up -j branchpoint -j tag1 cvs commit cvs up -r branch cvs tag tag2 cvs up -A cvs up -j tag1 -j tag2 cvs commit Which is how one usually does multiple merges. But lets say you have some changes you don't want to merge. So you purposefully move one of the tags past the version so those changes don't get looked at. Not something you could easily do with cvs automatically tracking it. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
Is there some reason why the -j's could not be recorded in the CVS directory, and corrected with each update? The joins shouldn't be recorded in the repository until the commits are done anyway. -j makes a notation in the CVS directory (or appends an existing one if multiple joins are done between commits), and -r and -A clear out the notations. At commit time, the notations could be recorded in the RCS files for future use. --- Forwarded mail from [EMAIL PROTECTED] On Wed, Jun 13, 2001 at 09:00:09PM -0700, Paul Sander wrote: If CVS had and equivalent to ClearCase' merge arrows, then a more intelligent choice could be made for the reference version, reducing the distances of the diffs and eliminating the needless conflicts. Of course, that's nearly impossible to do within CVS. cvs up -j change change change change cvs up change change change cvs up cvs commit compare to cvs up -j change change chang echange oop... don't like that find . -name '*.[ch]' | xargs rm cvs up change change change cvs up cvs commit Which is merged? which isn't? There would probably have to be an extra lot of special casing to handle the fact that this file had had a -j done onto it, but not yet committed. And if it had been deleted and updated, mark that -j as undone. Plus, let's say you do the following: cvs up -r branch cvs tag tag1 cvs up -A cvs up -j branchpoint -j tag1 cvs commit cvs up -r branch cvs tag tag2 cvs up -A cvs up -j tag1 -j tag2 cvs commit Which is how one usually does multiple merges. But lets say you have some changes you don't want to merge. So you purposefully move one of the tags past the version so those changes don't get looked at. Not something you could easily do with cvs automatically tracking it. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Maintaining branches...
Ralph Mack ([EMAIL PROTECTED]) wrote: [...] What I'm reading about branching and merging makes me think that a branch-merge pair on CVS is a one-way trip, that once you have merged from a branch you can't merge to that branch from the updated mainline and then merge back again. Another interpretation is that you have to specify your merge control points (from, to, last common ancestor) manually. For the first merge, CVS can figure the common ancestor (given only one -j option.) For subsequent merges, you don't want it to figure the common ancestor because if you allow it to, it will re-merge in the changes you already merged, potetially causing lots of conflicts that you've already resolved the first time. The typical sequence is something like: 1st merge: cvs tag before_merge_1 cvs tag -r from_branch merge_point_1 cvs update -dP -j merge_point_1 (resolve conflicts) cvs commit -m 'merged up to merge_point_1 from_branch 2nd merge: cvs tag before_merge_2 cvs tag from_branch merge_point_2 cvs update -dP -j merge_point_1 -j merge_point_2 (resolve conflicts) cvs commit -m 'merged up to merge_point_2 from_branch Does CVS branching and merging allow the developer to do the kind of rev-up/promote merge pattern that we do routinely with ClearCase? If you have to specify all three control points, shouldn't CVS be able to figure out the last common ancestor from the merge history? Is this another situation complicated by directories not being versioned? There is no merge history. As far as CVS is concerned, changes commited which are the result of a merge are indistiguishable from a situation where you just typed in those same changes again and commited them. CVS is finished with the merge operation as soon as the cvs update command completes. The subsequent commit is not a merge as far as CVS knows. CVS's idea of merge is, I think, pretty similar to: cvs diff -uN -r abc -r xyz | patch -p0 but with conflicts handled a bit differently With that in mind, your process seems a bit extreme, with more than the usual amount of branching and merging going on, vs. a typical CVS shop...(not that I know what that really is.) Note also, there is a subtle implication that a merge using 2 -j options differs from using just 1 -j option in that with 2 -j options, for files which are removed between the two tags, that removal is merged in without possibility of conflict. This is because for such a merge, CVS can't know that there really is a common ancestor, or what span of revisions to check for conflicting changes. (all it knows is two points... it is very much like running patch) You could be running a reverse merge, for instance, to undo changes, in which case a common ancestor is nonsense. Looking at this more (than I have before) it looks like the code calls RCS_merge in much the same way whether one or two -j options is given, so, assuming cvs update -j rev1 -j ref2, it looks like it takes rev1 to be the common ancestor, when in reality, it may not be a common ancestor at all. I think the magic is in cvs update finding the common ancestor (with one -j) and filling it in for rev1. So, if RCS_merge is taking rev1 to be the common ancestor and the basis for conflict detection, It kind of seems like the same logic should apply for file removals too...if you truncated the file to zero length, that and that would make a conflict, shouldn't deleting it make a conflict too? I'm not 100% sure about that. (Everytime I look at this part of the code it seems a bit weird. Sorry to go off on a tangent.) -- steve __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
