--- 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.
*
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,
--- 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:
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
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
[ 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
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
-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
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
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
--- 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
--- 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
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 )
[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,
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
[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
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
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
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
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
20 matches
Mail list logo
