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 this
> is one of the points where a significant benefit can be made
> for cvs iff we are a bit more aggressive in terms of breaking
> backwards compatibility. I know people will probably complain
> but I really really think we need to just bite the bullet and
> do this right.
> - Delete the whole concept of the -A option from update/checkout
That would leave a hole around the area of resetting sticky options,
("-kb", "-kk", etc.) though "cvs update -A" might not have been the right
thing to fill that hole in the first place.
> - 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"
isn't so hard to type, you don't even have to hit "shift".
> - Delete the whole concept of HEAD, instead generalize it to something
This I think can agree with.
> really useful and scaleable like
> <branchname>.latest - For the latest version on a branch
Some crappy code to do this would be approximately something like:
if (tag && strlen(tag) > 7 && strcmp( tag+(strlen(tag)-7, ".latest")
== 0 )
tag[(strlen(tag)-7] = '\0';
ok, that's an oversimplification. but this ".latest" thing doesn't do
anything
that the branch tag by itself doesn't do already, is my point, so I think I
have
to vote against that one.
> <branchname>.base - For the version where the branch sprouted
I haven't thought about BASE, or what it means, at all, not one whit, so I
haven't yet formed an opinion.
> - Allow importing directly to the main branch,
I think I agree with this, the key word being "allow".
> get rid of the import branch.
I don't agree with this. I'm not experienced with vendor
branches, but from reading what little I have about what's
going on there, there is a definite purpose and method to
the madness, I believe. I don't think they can or should be gotten
rid of. But I'm sure someone more experienced with vendor
branches will pipe up.
Perhaps there's even some reasoning related to vendor
branches which can explain a method to the madness
around "cvs diff" and "HEAD", though nobody has yet
explained it to me.
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. Changes to how "cvs import" works
for instance could be done independently from changes
to implement the "<branchtag>.base" thing for instance.
Also, grand plans on this list have a history of going
nowhere. :-)
-- steve
I think this would significantly improve the functionality
of cvs for users. And I think it might help clean up some
other wise narly special case handling in the code.
