info-cvs
[Top][All Lists]
Advanced

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

Re: importing vendor branches


From: Greg A. Woods
Subject: Re: importing vendor branches
Date: Thu, 3 May 2001 21:40:36 -0400 (EDT)

[ On Thursday, May 3, 2001 at 18:33:17 (-0400), Larry Jones wrote: ]
> Subject: Re: importing vendor branches
>
> Fergus's complaint is that anyone checking out the "head" of the tree
> between the time of the import and the time the merge is committed gets
> the newly imported version of files that have not been locally modified
> and the old version of files that have been locally modified.

Hmmm... yes, this is true, but I've never even heard of anyone doing
this by accident, let alone ever tripped over it myself.

I suppose if you had a lot of developers working on a really big
third-party project, as for example the group Brian Berliner was working
with when he first wrote CVS-II, and if those developers were prone to
checking out new working directories frequently, then one of them could
be far enough out of touch wiht waht's going on in the repo to trip over
such a situation, I suppose....

>   I think
> "inconsistent" is an accurate description of the state of the repository
> during that time.

I still wouldn't go so far as to call it "inconsistent" though.  All the
information's still there -- it's just the merge hasn't been done.  It
would of course help if the "cvs import" added a tag to all revisions on
the trunk that was related in some computationally derived way to the
prior release tag on the vendor branch.  That way you could identify an
inconsistent working directory programmatically (eg. on checkout or even
update).

I.e. the resulting working directory is definitely inconsistent, in
terms of having a working version of the source code, but the
*repository* itself is not in an inconsistent state.

> This has been listed in TODO for a long time:
> 
> 38. Think hard about using RCS state information to allow one to checkin
>     a new vendor release without having it be accessed until it has been
>     integrated into the local changes.

Yes, I'm aware of that one -- though I had thought it was so minor, at
least in the perspective it is apparently from, that it wouldn't even
really need to be thought about any further.

Certainly a two-phase import would solve the problem, but that would
drastically complicate the vendor branch feature and create an awful lot
of overhead that I think is, at least in general, far more trouble than
the "fix" would be worth.

Perhaps the somewhat silly tagging trick I outline above would at least
make it possible to warn a user when they're checking out an
inconsistent working directory.  You wouldn't necessarily know about an
inconsistency until either the first locally modified file was
encountered, and/or until the end of the checkout, but that should be
better than nothing.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

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