Ok, here's a refinement of my ".trunk' patch that gives
the trunk a branch-tag name, just like other branches
(from the user's perspective, the implementation is rather
different.)
You can also find this here:
http://www.geocities.com/dotslashstar/branch_patch.html
>From HACKING:
* Writ
Well, I see one problem with my patch already:
--- Stephen Cameron <[EMAIL PROTECTED]> wrote:
This part, from cvs.texinfo:
+
+ CAUTION: the special tag `HEAD' is interpreted by
+ the `cvs diff' command in a different way than it
+ is interpreted by any other cvs command. `cvs diff'
+ takes `-
Greg Woods wrote:
> [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ]
> > Subject: ".trunk" patch refinement
> >
> > Ok, here's a refinement of my ".trunk' patch that gives
> > the trunk a branch-tag name, just like
I wrote:
> Greg Woods wrote:
[...]
> OK, so exactly how is this [my .trunk patch] different from "-r1"?
> Seems like it's the
> same thing to me, which means it's an awful waste of coding effort,
> not
> to mention the extra typing necessary to use it... ;-)
Mike Little <[EMAIL PROTECTED]> on 06/19/2000 09:12:42 AM
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
cc: (bcc: Rex Jolliff/YM/RWDOE)
Subject: RE: ".trunk"
[EMAIL PROTECTED] wrote:
>
>
> I would just like to point out that trying to use CVS revision
> numbers as module or system version numbers is a bad, bad thing
> to do. This cannot be reiterated enough, and I realize that you
> did not suggest doing it Mike, but some people might get the
> mist
Greg Woods wrote:
> [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> > Subject: RE: ".trunk" patch refinement
> >
> > Would '-r1' work if some previous cvs admin had updated vast numbers of
> the
> > trunk revisions to 3
>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>>
>>> [...] OK, so exactly how is this different from "-r1"?
>>>
>>
>>Would '-r1' work if some previous cvs admin had updated vast numbers
of the
>>trunk revisions to 3.x (presumably when version 3.0 of the
[ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ]
> Subject: Re: ".trunk" patch refinement
>
> Since it's a very natural thing to do, lots of people have done
> it. It's easy (and correct) to say they should not have done
> that, but the
David Thornley <[EMAIL PROTECTED]> writes:
> Either way, any technique that assumes that all main trunk development
> is on rev numbers 1.* is useless to me, and probably to quite a few
> people.
And it's quite possible to get into that state without any misuse of CVS
at any point. It's worth r
I'm well aware that bumping trunk revisions to 2.x or greater is
pretty useless, and that tags are the right way to go, especially
since after you do it, newly-added files will still get 1.x
revisions. However...
On Mon, Jun 19, 2000 at 05:01:45PM -0400, Greg A. Woods wrote:
> However people sho
[ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> Subject: RE: ".trunk" patch refinement
>
> Would '-r1' work if some previous cvs admin had updated vast numbers of the
> trunk revisions to 3.x (presumably when version 3.0 of the product wa
[ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ]
> Subject: ".trunk" patch refinement
>
> Ok, here's a refinement of my ".trunk' patch that gives
> the trunk a branch-tag name, just like other branches
> (from the user
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 19, 2000 3:48 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: ".trunk" patch refinement
>
> [ On Saturday, June 17, 2000 at 21:41:49 (-
If they've migrated from sccs, this will have been done for them :-)
At 05:01 PM 6/19/00 -0400, Greg A. Woods wrote:
>However people should *not* ever be doing such silly things -- there are
>more corner cases than just this one whre they can get into trouble!
On Mon, Jun 19, 2000 at 05:13:10PM -0500, David Thornley wrote:
> Mike Little referred to "some previous cvs admin", and this is
> precisely what happened in my case. Some previous CVS admin
> put some of the rev numbers to 2.x, and there's no way I can put
> them back to 1.x.
You could probably
Russ Allbery wrote :
|| David Thornley <[EMAIL PROTECTED]> writes:
||
|| > Either way, any technique that assumes that all main trunk development
|| > is on rev numbers 1.* is useless to me, and probably to quite a few
|| > people.
||
|| And it's quite possible to get into that state without any
Stephen Rasku wrote :
|| What I don't understand is: If something is bad, why is it allowed.
|| If using this feature is dangerous, then it should be removed from
|| CVS.
It's not so much "bad" as it is irrelevant to the CVS way of doing
things - a distraction retained from historical roots.
"Greg A. Woods" wrote:
>
> [ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ]
> > Subject: Re: ".trunk" patch refinement
> >
> > Since it's a very natural thing to do, lots of people have done
> > it. It's easy
[ On Tuesday, June 20, 2000 at 10:41:16 (+0100), J. Cone wrote: ]
> Subject: RE: ".trunk" patch refinement
>
> If they've migrated from sccs, this will have been done for them :-)
Yeah, no thanks to the broken use of sccs2rcs. Unfortunately nobody
ever wrote an "
I was reading your patch to try and understand why .trunk is needed...
> "Stephen" == Stephen Cameron <[EMAIL PROTECTED]> writes:
Stephen> One or both @samp{-r} options can be replaced by a
Stephen> @samp{-D @var{date}} option, described above.
Stephen> +
Stephen> + CA
I havent really followed this thread much but when I looked into
implementing this and reviewed the code. Yikes, the HEAD stuff
scared the crap out of me in terms of funky things that work and
dont work.
I applaud the work being done to get us there but I think this
is one of the points where a
John Cavanaugh wrote:
> I havent really followed this thread much but when I looked into
> implementing this and reviewed the code. Yikes, the HEAD stuff
> scared the crap out of me in terms of funky things that work and
> dont work.
>
> I applaud the work being done to get us there but I think
I wrote:
> Also, though it might be nice to have a consistent
> vision for where we would like things to go, I don't
> think all these things necessarily need to be done
> at the same time.
Actually the next thing I'd like to see would be the
ability to specify -r branch and -D date option
This works :
cvs co -l -rb0808 -D "60 days ago" foo
% cvs -v
Concurrent Versions System (CVS) 1.10 `Halibut' (client/server)
--
Fabrice
Cameron, Steve writes:
> I wrote:
>
> > Also, though it might be nice to have a consistent
> > vision for where we would like things to go, I don't
>
[ On Wednesday, June 21, 2000 at 22:50:26 (-0700), John P Cavanaugh wrote: ]
> Subject: Re: ".trunk" patch refinement
>
> - Delete the whole concept of the -A option from update/checkout
With reference to sticky tags, yes I agree 100%. It does not cost that
much more to chec
Fabrice Lavier
> This works :
> cvs co -l -rb0808 -D "60 days ago" foo
> % cvs -v
> Concurrent Versions System (CVS) 1.10 `Halibut' (client/server)
[smc] Oh. That was easy. :-)
Hmm. I think I was remembering the code in "rtag.c",
and "tag.c" which forbids the combinatio
[ On Thursday, June 22, 2000 at 10:02:19 (-0500), Cameron, Steve wrote: ]
> Subject: RE: ".trunk" patch refinement
>
> ok, that's an oversimplification. but this ".latest" thing doesn't do
> anything that the branch tag by itself doesn't do al
On Thu, Jun 22, 2000 at 10:02:19AM -0500, Cameron, Steve wrote:
>
> John Cavanaugh wrote:
>
> > I havent really followed this thread much but when I looked into
> > implementing this and reviewed the code. Yikes, the HEAD stuff
> > scared the crap out of me in terms of funky things that work an
John P. Cavanaugh wrote, regarding his preference for "main" or "trunk"
over ".trunk":
> Partly for personal preference of liking main or trunk better than .trunk.
> But it also allows for main.latest (which I will admit is only to facilitate
> similarity with other branches)
So, it's partly for
John P Cavanaugh wrote:
>
> On Thu, Jun 22, 2000 at 10:02:19AM -0500, Cameron, Steve wrote:
> >
> > > - Name the main trunk "main" or "trunk" and just deal with the
> > > consequences of people that already have that branch name
> >
> > Why should we break things when it's not necessary? ".trunk
David Thornley wrote:
[...]
> .main.latest
> types easy too. (. is in the central part of the three basic rows
> of the QWERTY keyboard, and doesn't require a shift key.)
".main" is fine by me.
[...Regarding support for redundant ".latest" suffix for branch tags.]
>And similarity with the ma
On Fri, Jun 23, 2000 at 06:04:23AM -0700, Stephen Cameron wrote:
> John P. Cavanaugh wrote, regarding his preference for "main" or "trunk"
> over ".trunk":
>
> > Partly for personal preference of liking main or trunk better than .trunk.
> > But it also allows for main.latest (which I will admit i
--- John P Cavanaugh <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 23, 2000 at 06:04:23AM -0700, Stephen Cameron wrote:
> > John P. Cavanaugh wrote, regarding his preference for "main" or "trunk"
> > over ".trunk":
[]
>
> Actually its not consistent with other branch names because they dont
> beg
"Cameron, Steve" wrote:
>
> David Thornley wrote:
>
>
> [...Regarding support for redundant ".latest" suffix for branch tags.]
> >And similarity with the main trunk. There's no great harm in synonyms.
>
> Except people have to write the code to support them, spend the effort
> to understand
> > I may be slow today, but I don't see how merging the metadata is going
> > to accomplish all this [stuff that vendor branches do].
Merge Metadata can serve the same function as the vendor branch.
Typical scenario, a local copy of an open source project, maybe say cvs.
Ill describe a scenario
John P Cavanaugh wrote:
>
> > > I may be slow today, but I don't see how merging the metadata is going
> > > to accomplish all this [stuff that vendor branches do].
>
> Merge Metadata can serve the same function as the vendor branch.
>
> Typical scenario, a local copy of an open source project,
On Mon, Jun 26, 2000 at 10:24:37AM -0500, David Thornley wrote:
> John P Cavanaugh wrote:
> >
> > > > I may be slow today, but I don't see how merging the metadata is going
> > > > to accomplish all this [stuff that vendor branches do].
> >
> > Merge Metadata can serve the same function as the v
I have a new version of my ".trunk" patch (I sent it to bug-cvs
already but I didn't want to pollute everyone's mailbox
with a big patchfile twice, so I'm only sending this
URL to info-cvs...
Includes a new test case in sanity.sh for a revision "2.1"
Changes to docs, comments...minor stuff.
Th
(I think the subject line no longer applies)
Greg Woods wrote:
> (There could be a bit of a chicken&egg problem to solve for ".base"
> though -- I think you actually have to create it if you want it because
> of the late branching optimisation, which is something you cannot avoid
> if you want
On 22 Jun 2000, at 15:59, Greg A. Woods wrote:
>[ On Wednesday, June 21, 2000 at 22:50:26 (-0700), John P Cavanaugh wrote: ]
>> - Delete the whole concept of HEAD, instead generalize it to something
>> really useful and scaleable like
>>.latest - For the latest version on a branch
>>
41 matches
Mail list logo
