[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: update -j updates more than requested

From: Kaz Kylheku
Subject: Re: update -j updates more than requested
Date: Mon, 20 Jan 2003 13:28:59 -0800 (PST)

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

> 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 --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]