bug-cvs
[Top][All Lists]
Advanced

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

Re: Official sources vs. RCVS


From: Karl Fogel
Subject: Re: Official sources vs. RCVS
Date: 30 Jan 2001 09:24:41 -0600

I haven't looked at the patch, but it seems that the most important
part will be the documentation -- guiding people as to how to use
these features.  I hope it's thorough. :-)

-K

"Cameron, Steve" <Steve.Cameron@COMPAQ.com> writes:
> Karl Fogel wrote:
>   [...] 
> > Seems useful; if understand it correctly, it can alleviate the need
> > for branch-point tags, right?
> > 
>       [smc]  Yes, that's what the ".origin" part does
> 
>       And, the ".trunk" part
>       can do essentially what "cvs update -A" does, except
>       it doesn't fry your "-kb" and "-kk"  sticky options, 
>       so you can switch between the trunk and a branch 
>       easily, and allows you to do "cvs diffs"  or other 
>       operations vs.  the trunk with out relying on using 
>       numeric revision tricks that may not always work 
>       if your repository  was made by directly importing 
>       RCS *,v files, or if  somebody has unwittingly done 
>       "cvs commit -r 2.0"
> 
>       One questionable aspect of the patch is that it
>       allows the combination ".trunk.origin", whcih will 
>       return the oldest revisions on the trunk.  I call it 
>       questionable because as time passes and files 
>       are "cvs added" to the trunk, 
>       the list of files that ".trunk.origin"
>       refers to will grow, unlike "branchtag.origin", if I'm
>       remembering this right.  I think this is because
>       when files are cvs added to a branch, a dead
>       revision is added first, but when adding a new
>       file onto  the trunk, no such dead revision is 
>       added first.  In any case, the combination of
>       ".trunk.origin" as a single tag probably isn't too 
>       useful anyway.  It should either return what it 
>       does now, (a list that grows over time), or, the
>       empty set, which would be fairly useless, or,
>       maybe it should just be forbidden, as senseless.
>       I implemented what seemed to the least senseless
>       thing without forbidding it altogether.
> 
> 
>       -- steve
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Bug-cvs mailing list
> Bug-cvs@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-cvs



reply via email to

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