Re: am I misunderstanding what HEAD refers to?

[Ted Stern]

On 05 Oct 2007 11:04:38 -0700, Dennis Jones wrote:
>
> "Ted Stern" <address@hidden> wrote in message 
> news:address@hidden
>
>> At this point, I want to check to make sure no changes have gone into
>> the trunk between BRANCHNAME_MERGE_HEAD and right now.
>>
>> So my first naive thought is to do a diff.  Note that I'm currently
>> sitting in my branchname sandbox:
>>
>>    cvs diff -r BRANCHNAME_MERGE_HEAD -r HEAD 1>stdout 2>stderr
>
> I'm not sure why nobody eslse has suggested this, but since 
> BRANCHNAME_MERGE_HEAD always refers to a point on the trunk and you want to 
> diff the trunk, why not go to the trunk and do the diff from there?  IOW, 
> instead of sitting on your branch and trying to do the diff from there, just 
> switch over to the trunk and do it.  That way, HEAD will refer to the trunk 
> instead of the branch, and your diff should work as expected.
>
> Am I missing something?
>
> - Dennis 
>

Here's the issue.  We're trying to set up scripts to automate most
aspects of branching and merging for users who seldom use CVS.  And we
also want to provide a standardized front end so that we can
eventually switch to subversion without having a huge retraining time
for the users.

In this transitional period, we want to keep the users from having to
wait while a thousand files get tagged or updated.  And since a user
will typically be working on their own branch, we want to avoid
requiring them to have a trunk (or parent branch) checkout in addition
to the bug checkout.

When working properly, cvs diff is a pretty fast way to detect
differences between branches, and is also easy to parse.

To do what you suggest, the user would have to do a 'cvs update -dA'
[or 'cvs update -d -r parentbranch' if not branching from the trunk].
This can take almost as long as tagging.  Then they would have to 'cvs
update -d -r branchname' to get back to the branch checkout they were
working on.  The other question is whether HEAD will mean what _YOU_
think it means, even when you are in a trunk checkout.  If it always
points to the most recently checked in version, even if it is not on
the current branch, then the same problem will still apply.

Ted
-- 
 dodecatheon at gmail dot com
 Frango ut patefaciam -- I break so that I may reveal