update -j updates more than requested

2003-01-20 Thread Alicia Jones
Greetings,

I'm having the following problem with 'update -j'.  Any help is
appreciated.

I have an (untagged) working copy that was originally checked out from
the main trunk.  More files have been checked into the main trunk since 
then, so there are files/changes on the trunk that are not in my 
working copy.  My working copy also has uncommitted adds/changes.

I now want to merge in the changes from another branch made off of HEAD
into my working copy.  The branch is further down the trunk than my 
working checkout, but not at the end of the trunk.

I expected the following to work:
   cvs update -j BRANCHTAG working_dir

However, this not only merges in the changes from the branch, but it's
ALSO brings my working dir up to date with the LATEST (past my checkout
AND the branch) versions checked in on the main trunk.  I only want the
changes from the BRANCH, without picking up any changes on the trunk.

'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the
same
result, which is really strange.

Anyone know how I can get what I want?   BTW, this is CVS version
1.10.7.

TIA...

AJ


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: update -j updates more than requested

2003-01-20 Thread Kaz Kylheku
On Mon, 20 Jan 2003, Alicia Jones wrote:

 I have an (untagged) working copy that was originally checked out from
 the main trunk.  More files have been checked into the main trunk since 
 then, so there are files/changes on the trunk that are not in my 
 working copy.  My working copy also has uncommitted adds/changes.
 
 I now want to merge in the changes from another branch made off of HEAD
 into my working copy.  The branch is further down the trunk than my 
 working checkout, but not at the end of the trunk.

Ah, well, then relative to you, that branch consists of all the main
trunk work up to that branching point, and then all the work on the
branch.

 I expected the following to work:
cvs update -j BRANCHTAG working_dir
 
 However, this not only merges in the changes from the branch, but it's
 ALSO brings my working dir up to date with the LATEST (past my checkout
 AND the branch) versions checked in on the main trunk.  I only want the
 changes from the BRANCH, without picking up any changes on the trunk.

In that case, there has to be a branchpoint tag which marks the point
on the trunk where the branch was made. You merge using:

   update -j branch-start-point -j branch

This will do the right thing. If, alas, no such tag was made, you might
be able to approximate it if you can guess the date and time when the
branch was sprouted.

People should practice making branchpoints. Without them, it's hard to
take a branch to be a changeset which can be grafted into distant
places in the revision tree.

 'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the
 same
 result, which is really strange.
 
 Anyone know how I can get what I want?   BTW, this is CVS version
 1.10.7.

You should consider upgrading to 1.11, though not specifically for this
problem. A lot of debugging has happened since 1.10.7.

There was a branchpoint patch floating around to add special syntax for
implicitly referring to the base revisions of a branch, thereby
avoiding the need for a branchpoint tag. I'm not sure whether this has
been rolled into the official CVS sources.

-- 
Meta-CVS: directory structure versioning; versioned symbolic links;
versioned execute permission; versioned property lists; easy branching
and merging and third party code tracking; all implemented over the
standard CVS command line client -- http://freshmeat.net/projects/mcvs



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: update -j updates more than requested

2003-01-20 Thread Alicia Jones
Kaz Kylheku wrote:
 
 On Mon, 20 Jan 2003, Alicia Jones wrote:
 
  I have an (untagged) working copy that was originally checked out from
  the main trunk.  More files have been checked into the main trunk since
  then, so there are files/changes on the trunk that are not in my
  working copy.  My working copy also has uncommitted adds/changes.
 
  I now want to merge in the changes from another branch made off of HEAD
  into my working copy.  The branch is further down the trunk than my
  working checkout, but not at the end of the trunk.
 
 Ah, well, then relative to you, that branch consists of all the main
 trunk work up to that branching point, and then all the work on the
 branch.
 

Yes, but fortunately I was able to successfully bring my working dir 
up to date with the point where the branch forked off without problem
(using a regular cvs update).  So I really should take that out of the 
equation.  Let's assume I was up-to-date at the time the branch was
forked.


  I expected the following to work:
 cvs update -j BRANCHTAG working_dir
 
  However, this not only merges in the changes from the branch, but it's
  ALSO brings my working dir up to date with the LATEST (past my checkout
  AND the branch) versions checked in on the main trunk.  I only want the
  changes from the BRANCH, without picking up any changes on the trunk.
 
 In that case, there has to be a branchpoint tag which marks the point
 on the trunk where the branch was made. You merge using:
 
update -j branch-start-point -j branch
 


I think that's what I'm doing...  
I have a cvs branch tag (BRANCHTAG) on the branch which of course points
to the end of the branch I want.  I also have a regular (i.e.
non-branch)
tag (BPOINTTAG) on the main trunk at the point where the branch I want 
forked off from the trunk.  So it seems that either of:

   update -j BRANCHTAGOR
   update -j BPOINTTAG -j BRANCHTAG
 
should have worked.  However, both of these command get me both the
changes on the branch AND the changes between the revisions currently in
my working dir and the most recent checkins on HEAD.

It's as if it doing both the 'cvs update -j 1 -j 2' AND a regular 
'cvs update'.  I didn't think that's what was supposed to happen.



 This will do the right thing. If, alas, no such tag was made, you might
 be able to approximate it if you can guess the date and time when the
 branch was sprouted.
 
 People should practice making branchpoints. Without them, it's hard to
 take a branch to be a changeset which can be grafted into distant
 places in the revision tree.
 
  'cvs update -j NONBRANCHSTARTTAG -j BRANCHTAG working_dir' gives the
  same
  result, which is really strange.
 



  Anyone know how I can get what I want?   BTW, this is CVS version
  1.10.7.
 
 You should consider upgrading to 1.11, though not specifically for this
 problem. A lot of debugging has happened since 1.10.7.
 
 There was a branchpoint patch floating around to add special syntax for
 implicitly referring to the base revisions of a branch, thereby
 avoiding the need for a branchpoint tag. I'm not sure whether this has
 been rolled into the official CVS sources.
 
 --
 Meta-CVS: directory structure versioning; versioned symbolic links;
 versioned execute permission; versioned property lists; easy branching
 and merging and third party code tracking; all implemented over the
 standard CVS command line client -- http://freshmeat.net/projects/mcvs

AJ


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs