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, 2
--- 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.
>--- 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 )
>>
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 + (
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
>--- 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 al
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 c
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
>--- 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 c
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
>--- 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
>>
>--- 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
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 t
aul 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 th
>--- 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!
>--- 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 corr
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
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 (
> -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 versi
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
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 o
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 (
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,
>
[ 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
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
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 betwe
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 imp
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" an
[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
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 th
[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,
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 in
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 se
33 matches
Mail list logo
