Re: Maintaining branches...
Ralph Mack wrote: > > Hello, all, > > I have a couple of questions. > > First a question for my home environment - has anybody managed > to integrate CVS into Visual Age for Java? I got the Zeus-SCC > stuff and I tried to use it from VAJ but it killed the VAJ > environment. I may have had it set up wrong, though. If I at > least know that it is supposed to work, it will help me focus > my efforts. I don't know what Zeus-SCC is -- I use VAJ with CVS, but without using the external SCM integration. There's a tool "vaj2cvs" that was written by Kevin Grittner; it uses the tools integration API, and in my experience works very well most of the time. Give it a try... http://vaj2cvs.sourceforge.net/ Cheers, -bn ___ 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
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...
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 12:57:30PM -0400, Greg A. Woods wrote: > [ 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, > > [...] At commit time, the notations could be recorded in the RCS > > files for future use. > > That's the trick. [...] Is doing it as part of the commit message sufficient? NO! One wants to be able to query based on this; more importantly, CVS itself needs to be able to do so to implement merge-tracking. > How do you do that without impacting RCS compatability??? The RCS file format is extensible; this shouldn't be a problem. I posted some time ago on this subject. I was going to say "check the archives", but then did so myself and discovered that the info-cvs archive at egroups stops in Dec. 2000. So here's a repost of my original message. Is there another archive, so I won't have to do this in future? (Greg, this was written in the context of binary-file support. Please try to ignore that, and just use it as background :-) On Thu, 4 Jan 2001 12:54:12 -0500, I wrote: > Subject: Re: Proposal to fix CVS binary file implementation > > On Thu, Dec 28, 2000 at 03:22:36PM -0600, David H. Thornley wrote: > > It could be worthwhile expanding the RCS > > format to do some better handling of binary files. It would be > > possible to improve the handling of binary files while keeping > > most of the code base. > > The extension to the RCS format (ie. the data-storage layer) > should be a general one. It should provide for storing an > arbitrary set of named attributes (ie. key/value pairs) per > revision. There should also be a global set, whose attributes > apply to all revisions (as the keyword-expansion setting > currently does). > > Then the upper layers (ie. CVS proper) can define attributes to > suit its purposes, eg: > - binary/text flag > - MIME type > - keyword-expansion preferences > > (Whether these specific attributes should be per-revision or > global is open to debate -- indeed, the debate is currently > happening -- but in either case, under my proposal the decision > does not affect the RCS layer.) > > More things that fall out of this: > - One can imagine adding a per-revision attribute that says > where in the sandbox this ,v file lives. Poof -- the > revision-controlled mapping that Paul Sander (I think) was > talking about. (There'd still be a need to map the other > way, from sandbox name to ,v file -- but maybe the > CVS/Entries file could do that). > > - One could add attributes for things like file permissions and > the like -- anything that should be revision-controlled, but > currently isn't. > > - Another attribute could be the filesystem object type (so > named because "file type" is ambiguous; it can also refer to > MIME type). More attributes to contain symlink values, > device numbers, etc. > > - Expansion of arbitrary keywords (subject to keyword-expansion > settings of course): if there's a "Foo" attribute, and the > file contains a "$Foo$" keyword, expand it. (Needs an > interface for setting them; to prevent people from using this > to break CVS's own attributes, perhaps prepend "USER_" to all > attributes set via the UI.) > > Any number of worthwhile proposals have foundered on the > RCS-compatibility problem. So if it has to break, break it > *once* -- in a general-enough way that the RCS layer need never > change again. > > > Looking at rcsfile(5), I find that provision has already been > made for adding new metadata, both per-revision and globally -- > the "newphrase" construction in the grammar. So perhaps the > format doesn't have to break after all; what I'm suggesting is > already basically there. Rather than adding an attribute > mechanism, CVS could just define "newphrase"s where necessary, > since, as David Thornley points out, CVS has internalized its RCS > access, and is thus no longer dependent on the RCS code itself. > (I just checked; RCS 5.7 can handle files with custom metadata, > but it prints a warning. So even if CVS does extend the format > in this way, that won't prevent people from using RCS to get at > the data in an emergency.) > > If CVS opts for adding "newphrase"s, enhancing binary-file > handling is a matter of defining one or more of them to contain > the necessary metadata, and having CVS *ignore* the current > keyword-expansion flag for any ,v file which contains the &
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote:
> [ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ]
> > 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?
This can already be accomplished with external scripts that make use of
magic values in commit messages.
And even this, it only handles very special cases of merges. That is, were
all changes on one branch are merged into another.
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.
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...
Mike Castle wrote: > On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote: > > That's the trick. How do you do that without impacting RCS compatability??? > > Is doing it as part of the commit message sufficient? > > This can already be accomplished with external scripts that make use of > magic values in commit messages. > > And even this, it only handles very special cases of merges. That is, were > all changes on one branch are merged into another. Why? There are other technical/usablity problems with this (maybe a nitpick since much of this data could still be made useful, but I think it would be hard to make CVS aware that a user had deleted the merged data from a file manually), but I don't see any reason why both tags couldn't be stored for any merge. Well, tags could be stored, but that would be useless... individual file names and revisions describing each diff would be necessary since tags can be moved. Assigning change set names (perhaps only a timestamp though user, host, and workspace might be useful information in the logs) would be useful as well, I think. > 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? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Photons have mass? I didn't know they were catholic! ___ 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 12:57:30PM -0400, Greg A. Woods wrote: >> [ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ] >> > 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? >This can already be accomplished with external scripts that make use of >magic values in commit messages. Relying on the users to type in this info is a notoriously unreliable method to track this stuff. It's better to have the tool do it instead, especially since it has already been given the necessary info once. >And even this, it only handles very special cases of merges. That is, were >all changes on one branch are merged into another. >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. All that's recorded is the notion that some merge has been performed. There's no value judgement on what features of which branch survived the merge. The goal here is to prevent redundant conflicts because the common ancestor is always too distant after the first merge. Presumably, if a feature did not survive an early merge, it's intended to be omitted from all future ones. So, I think that your preferred case is the one that's served. If you really need to go back to pick up an abandoned feature, then it's still possible to supply the branch point label with a second -j option. Also, I don't believe that the granchild branch is an issue; it's a merge like any other. And the merge can also draw from an ancestor, which is handled equally well. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
Agreed. The additional meta-data are needed to make the proper choice of the common ancestor (i.e. default common contributor). --- Forwarded mail from [EMAIL PROTECTED] On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote: > [ 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, > > [...] At commit time, the notations could be recorded in the RCS > > files for future use. > > That's the trick. [...] Is doing it as part of the commit message sufficient? NO! One wants to be able to query based on this; more importantly, CVS itself needs to be able to do so to implement merge-tracking. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
Sounds like two more command line options are in order: One to set the default behavior in the .cvsrc file, the other to override that setting on the command line. --- Forwarded mail from [EMAIL PROTECTED] 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? --- 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] >Mike Castle wrote: >> On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote: >> > That's the trick. How do you do that without impacting RCS compatability??? >> > Is doing it as part of the commit message sufficient? >> >> This can already be accomplished with external scripts that make use of >> magic values in commit messages. >> >> And even this, it only handles very special cases of merges. That is, were >> all changes on one branch are merged into another. >Why? There are other technical/usablity problems with this (maybe a nitpick >since much of this data could still be made useful, but I think it would be hard >to make CVS aware that a user had deleted the merged data from a file manually), >but I don't see any reason why both tags couldn't be stored for any merge. >Well, tags could be stored, but that would be useless... individual file names >and revisions describing each diff would be necessary since tags can be moved. I don't see the need to include filenames in the notations, given that joins can be done only within the contents of a single RCS file. If CVS is extended to allow merging across multiple version histories, then the contributing RCS files must be recorded. Note that this is a hard problem in the event that multiple repositories are involved, because the value of CVSROOT can also change over time. >--- 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 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 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? If so, then the mechanism we're discussing will support this case. Version 1.1.0.3 would be recorded as an ancestor of version 1.2, which would later be used to identify version 1.1.0.3 as the common contributor for the next merge. >--- 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 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. -- | | /\ |-_|/ > 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...
>--- 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...
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 -r 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...
>--- 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...
Just a couple of brief comments... >--- Forwarded mail from [EMAIL PROTECTED] >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 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. >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 -r The "cvs update" command performs this function, using the -j options. >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. >--- 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 Sat, Jun 16, 2001 at 09:25:10AM -0700, Paul Sander wrote:
> 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?
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.
Except that I would expect that there should be no conflicts (stemming from
the re-application of a set of changes any).
That's why I think it should be a multipass system. 1.1.0.2 - 1.1 as one
diff, 1.1.0.5 - 1.1.0.3 as another set of diffs.
I would imagine that the sets of diffs would be built up, and applied in
turn. As each set was applied, whatever necessary tracking would be done
in local files. And as soon as any conflict occurs, patching would stop.
This could result in an incomplete application of patches, but there is
nothing to prevent the process from picking up where it left off after
resolution.
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 Sat, Jun 16, 2001 at 09:25:10AM -0700, Paul Sander wrote: >> 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? >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. >Except that I would expect that there should be no conflicts (stemming from >the re-application of a set of changes any). There may not be repeated conflicts (between deltas already applied during successive merges), but on the other hand some of the deltas between 1.1.0.2 and 1.1.0.3 would be skipped during the second merge. This is probably an intolerable situation. >That's why I think it should be a multipass system. 1.1.0.2 - 1.1 as one >diff, 1.1.0.5 - 1.1.0.3 as another set of diffs. >I would imagine that the sets of diffs would be built up, and applied in >turn. As each set was applied, whatever necessary tracking would be done >in local files. And as soon as any conflict occurs, patching would stop. >This could result in an incomplete application of patches, but there is >nothing to prevent the process from picking up where it left off after >resolution. I don't believe we're talking about tracking individual deltas here, just tracking which versions contribute to each merge. In that light, I don't see how what you propose could be done. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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
