Re: RE .trunk patch refinement
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 vendor branch. Typical scenario, a local copy of an open source project, maybe say cvs. Ill describe a scenario of how you could use this hypothetical cvs to develop the features to get to the hypothetical version. What you are proposing is to use the trunk as the vendor branch, and the equivalent of keeping a "last-merged" tag on it to merge onto a branch. Sort of. Its a bit more than that though, but you do have the basic concept. This is the sort of functionality that took me three days or so to write perl programs to handle (interfacing with CVS, of course) that were tailored for our development process and which catch a lot of common errors in process and procedure. Specifically, the "merge metadata" idea seems to be nothing more than keeping a "last-version-merged" tag on each branch, and updating it accordingly. (Except that it is not shown to have the ability to *not* merge a change that should not be merged - whereas it's always possible to move the "last-version-merged" tag without actually merging. Presumably such a facility would have this ability, but it's still not looking to me like a great improvement.) What you have done is the simple version of what Im looking for. Your example wouldnt handle multiple branches (say 4 or 5) and merging between them. It is *significant* and anyone who has used a real tool like ClearCase understands what Im talking about. Ill admit its really hard until you have seen it in action and the power that it provides. However, the recommended "-j:yesterday" works very well in this scenario, provided of course that you don't import vendor branches more than once every day or two. We don't here; I don't know about your shop. Its a simple use model that doesnt work real well for more complex things. So, now that you've described this, what is the difference between what you've described and what CVS does? The difference I can see is that you want to put the vendor releases on the main trunk, whereas CVS puts them on a labelled branch. Obviously, in this case, merged metadata can do what CVS is doing. However, I really don't see that there is any advantage to doing so. Think beyond one branch to something like 4 or 5. This number of branches is quite reasonable for very large projects doing multiple parallel streams of development. This model also allows you to have multiple private branches doing all kinds of various things that are unrelated to each other. Perhaps one to add rename support, another to add merge meta-data etc. And the difference between this and intelligent use of CVS would be? We can do things like that already. It requires a little intelligent use of tags. I want the tool to do this for me, I shouldnt have to. More importantly my users shouldnt have to, primarily because they forget. This use can be codified into wrappers that people will use instead of raw CVS commands. Nothing you've described is beyond what can be done with intelligent tag use. It would probably be easier to use for somebody starting with CVS being installed and projects starting yesterday, but that's a pathological case for any support software. There are instructions in the Cederqvist about how to do this sort of thing. This isn't anything new, or anything that hasn't been considered before. Err, its new to CVS, but its standard on tools with real horsepower. Dont get me wrong CVS is great because its free, but it also cant compete with the industrial tools. So, merging metadata (as you put it) would be a convenience, but as far as I can tell nothing more. If it requires more active CVS administration, it might well be a loss. It doesnt require an ounce of administration, but we gain back pounds in functionality. Um, there hasn't been all that much pain. I can see how there would be if we weren't using a tool like CVS, but with CVS we've got this stuff organized so almost all the branch synchronization stuff is routine. Im glad things are working for you and the scripts you have written. But Im more in favor of the tool have the underlying functionality to do this. If we had merge meta-data and directory versioning, CVS would kick major butt even agains the big commercial guys. Fundamentally *that* is what I would like to see. --- John Cavanaugh Agilent Technologies RD Program Manager 1400 Fountaingrove Pkwy CAD Data Store Santa Rosa, CA 95403-1799 Email: [EMAIL PROTECTED]Phone: 707-577-4780
RE: .trunk patch refinement
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 the sake of consistency. Well, ".trunk" is perfectly
consistent too. It's a branch tag name for the trunk. If you want the
latest stuff from a branch, you use the branch tag name. If you want the
latest stuff from the trunk, you use the branch tag name: ".trunk"
(my words, and here I confuse BASE, and ".base" which are completely
different).
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.
Its nice to be able to easily figure out where your branch sprouted from
using an abstract mechanism.
Yes it is, actually it's more than nice, it's essential, which is
why everybody manually tags this point before creating a branch,
except for newbies, who learn the hard way.
So I've thought about it a bit more and written some rough code
(below). (I didn't put the code in patch form because it's not
quite cooked yet and it would be a bit irresponsible to put it
out there in such easily edible form.)
These changes were made to rcs.c, and TAG_ORIGIN was #defined to
".origin", (to avoid confusion with BASE, I didn't use ".base"
but of course we can #define TAG_ORIGIN to be whatever everybody
likes)
Anyway it seemed to work with "update", "checkout", "diff" and
"rdiff", but then I tried sanity.sh, and it failed "make remotecheck"
(I forget which test, something to do with removing a branch tag.)
I'm not sure why, I would have though my code would only fire if you
used a tag of the form xxx.origin, but that's where things stand now.
Anyway, one thing I haven't figured out is what to do for the case
of the trunk, e.g. ".trunk.origin", (and/or maybe just ".origin" by
itself) The super easy but surely wrong implementation is just
return "1.1" in that case maybe? I'm not sure how to implement it
correctly though. Also, what should be done about the
"force_tag_match" case? I'm not sure that even makes sense
with ".origin", so just ignore it?
Anyway, here's a snippet of the code that I'm working on:
-- steve
/*
* Find the revision for a specific tag.
* If force_tag_match is set, return NULL if an exact match is not
* possible otherwise return RCS_head (). We are careful to look for
* and handle "magic" revisions specially.
*
* If the matched tag is a branch tag, find the head of the branch.
*
* Returns pointer to newly malloc'd string, or NULL.
*/
char *
RCS_gettag (rcs, symtag, force_tag_match, simple_tag)
RCSNode *rcs;
char *symtag;
int force_tag_match;
int *simple_tag;
{
char *tag = symtag;
int tag_allocated = 0;
if (simple_tag != NULL)
*simple_tag = 0;
/* make sure we have something to look at... */
assert (rcs != NULL);
/* XXX this is probably not necessary, --jtc */
if (rcs-flags PARTIAL)
RCS_reparsercsfile (rcs, (FILE **) NULL, (struct rcsbuffer *) NULL);
/* If tag is "HEAD", special case to get head RCS revision */
if (tag (STREQ (tag, TAG_HEAD) || *tag == '\0'))
#if 0 /* This #if 0 is only in the Cygnus code. Why? Death support? */
if (force_tag_match (rcs-flags VALID) (rcs-flags INATTIC))
return ((char *) NULL); /* head request for removed file */
else
#endif
return (RCS_head (rcs));
/* If tag is "TRUNK", special case to get trunk RCS revision */
if (tag (STREQ (tag, TAG_TRUNK) ))
return (RCS_trunk (rcs));
if (!isdigit ((unsigned char) tag[0]))
{
char *version;
/* add this for ".origin" */
/* if asking for the ".origin" of a branch tag, then find it */
if ( strlen(tag) strlen(TAG_ORIGIN)
strcmp(tag+strlen(tag)-strlen(TAG_ORIGIN), TAG_ORIGIN) == 0)
{
char *branchtag;
branchtag = xstrdup(tag);
strncpy(branchtag, tag, strlen(tag) - strlen(TAG_ORIGIN));
/* cut off the ".origin" */
branchtag = xstrdup(tag);
branchtag[ strlen(branchtag) - strlen(TAG_TRUNK)-1] = '\0';
version = RCS_getbranchoriginrev(rcs, branchtag);
free(branchtag);
return(version);
}
[..]
/*
* Get the origin of the specified branch.
* If the branch does not exist,
* return NULL
*
* Note, force_tag_match is IGNORED. I'm not sure what it should do,
* return "1.1", or the lowest numbered version? Seems questionable.
*
* What about ".trunk"?
*
* A lot of this code was copied mercilessly from RCS_getdatebranch
*
*/
char *
RCS_getbranchoriginrev (rcs, branch)
RCSNode *rcs;
char *branch;
{
char * version;
char *cur_rev =
Re: .trunk patch refinement
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" isn't so hard to type, you don't even have to hit "shift". 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) .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.) - 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 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. Well sort of, I included it just for similarity with branch.base And similarity with the main trunk. There's no great harm in synonyms. 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. Its nice to be able to easily figure out where your branch sprouted from using an abstract mechanism. Or an explicit tag. One thing that everybody says is to tag the base of any branch being cut. Any more or less mechanical thing that lots of people say should always be done is a prime candidate for automation. - 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. The vendor branch in my opinion is a gross hack in an attempt to mask some really deficient functionality in cvs, namely merge meta data. If we had merge meta data we would never need the vendor branch. Yes it would be a different model, and yes Im going out on a limb here, but it would be a much better model. I think we need to keep the vendor branch or equivalent functionality. Some of the things we need to do: - Restore earlier releases, even if the guy who installed them threw them out - Merge the changes we've made from the old release to the new release - Keep track of which changes were made by the vendor and which locally I may be slow today, but I don't see how merging the metadata is going to accomplish all this. For those interested there are some cosource.com project and funding related to these items. CVS Advanded Merge Metadata Support (Currently at $3700) http://www.cosource.com/cgi-bin/cos.pl/wish/info/187 There's an issue that I didn't see covered in the advanced merge issue list, which is when somebody makes a change to a branch that should not be merged forward. One example might be that a bug has to be fixed on a branch, but it was fixed in a different way on head, along with other changes. It shouldn't be difficult to say "this change is only for this branch, and should not be merged". (In my shop, we maintain merged tags for branches, and simply advance the tag for changes that should not be propagated.) -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
Re: .trunk patch refinement
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 is only to facilitate similarity with other branches) So, it's partly for the sake of consistency. Well, ".trunk" is perfectly consistent too. It's a branch tag name for the trunk. If you want the latest stuff from a branch, you use the branch tag name. If you want the latest stuff from the trunk, you use the branch tag name: ".trunk" Actually its not consistent with other branch names because they dont begin with a ., but I dont really care. For our use here I would just redefine it to be main and life would go on. These changes were made to rcs.c, and TAG_ORIGIN was #defined to ".origin", (to avoid confusion with BASE, I didn't use ".base" but of course we can #define TAG_ORIGIN to be whatever everybody likes) I like origin, good idea. Can you reference branchname.base for example to get a diff from where you last updated/checked out from?? Anyway, one thing I haven't figured out is what to do for the case of the trunk, e.g. ".trunk.origin", (and/or maybe just ".origin" by itself) The super easy but surely wrong implementation is just return "1.1" in that case maybe? I'm not sure how to implement it correctly though. You are right, returning 1.1 is definitely not the right answer. Instead probably returning the first revision in the file is the correct answer. And yes at times they are different, especially for those of us that migrated from rcs - hms - cvs. We have stuff that started on 150.1 --- John Cavanaugh Agilent Technologies RD Manager 1400 Fountaingrove Pkwy CAD Data Store Santa Rosa, CA 95403-1799 Email: [EMAIL PROTECTED] Phone: 707-577-4780 707-577-3948 (Fax) --- Unix is a user-friendly operating system. It just picks its friends more carefully than others. -- Unknown ---
Re: RE .trunk patch refinement
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 of how you could use this hypothetical cvs to develop the features to get to the hypothetical version. - You import the initial rev onto the main branch. (Say 1.10.8 or whatever) - You create your own private branch (called named_trunk) to make your changes for say the naming of the main trunk - Lots of work happens on cvs to fix bugs etc, or to add new subcommands like lsvtree. - You now import a new rev onto the main branch (Say 1.10.9 or something) - Now to update your private branch you just do a merge from the main branch by doing something like "cvs up -j main" - Even more work happens on cvs to fix bugs etc, or to add new subcommands - You now import a new rev onto the main branch (Say 1.10.10 or something) - Now to update your private branch you just do a merge from the main branch by doing something like "cvs up -j main". But the difference now is that it only merges in the differences from your last merge. This model also allows you to have multiple private branches doing all kinds of various things that are unrelated to each other. Perhaps one to add rename support, another to add merge meta-data etc. And how did merging (meta)data get into this thread? I'm not signing up for _that_, no matter how many people refuse to change the subject line. ;-) Wy too hard, and I'm not really sure I even like the idea anyway. -- steve I agree its hard, but its very useful for big software projects with multiple parallel lines of development its essential. If you havent done multiple parallel lines of development (ie. like 3 or more) you wont see the benefit because you havent felt the pain. Serious tools like ClearCase have these, until cvs does it wont be considered in the same league as ClearCase. --- John Cavanaugh Agilent Technologies RD Program Manager 1400 Fountaingrove Pkwy CAD Data Store Santa Rosa, CA 95403-1799 Email: [EMAIL PROTECTED]Phone: 707-577-4780 707-577-3948 (Fax) --- Be happy with your progress, but always discontented enough to continue to improve your skills. -- Unknown ---
Re: .trunk patch refinement
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 - Name the main trunk "main" or "trunk" and just deal with the consequences of people that already have that branch name - Delete the whole concept of HEAD, instead generalize it to something really useful and scaleable like branchname.latest - For the latest version on a branch branchname.base - For the version where the branch sprouted (ie. the base from the parent branch) - Allow importing directly to the main branch, get rid of the import branch. 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. --- John Cavanaugh Agilent Technologies RD Program Manager 1400 Fountaingrove Pkwy CAD Data Store Santa Rosa, CA 95403-1799 Email: [EMAIL PROTECTED] Phone: 707-577-4780 707-577-3948 (Fax) --- Add little to little and soon there will be a big pile. -- Ovid ---
RE: .trunk patch refinement
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.
RE: .trunk patch refinement
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 options simultaneously, that seems to me like a big hole that needs to be filled more urgently than those things John C. mentioned. There's already code in rcs.c, specifically RCS_getdatebranch(), that might already do the difficult part of this..., but I haven't looked at it very hard, so I don't know if it works the way the name and the comments say it works. -- steve
RE: .trunk patch refinement
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 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 options simultaneously, that seems to me like a big hole that needs to be filled more urgently than those things John C. mentioned. There's already code in rcs.c, specifically RCS_getdatebranch(), that might already do the difficult part of this..., but I haven't looked at it very hard, so I don't know if it works the way the name and the comments say it works. -- steve
RE: .trunk patch refinement
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 combination of "-r" and "-D" I forgot "checkout", and "update" too, I think, can do this though.
.base proposal (was RE: .trunk patch refinement)
(I think the subject line no longer applies) Greg Woods wrote: (There could be a bit of a chickenegg 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 to maintain repo compatability.) I don't understand what you mean. By "create it" do you mean create some actual "x.base" tags in the RCS files? I know, that given only a revision number, that revision may be on multiple branches and each of those branches might have a different ".base", so computing ".base" given only a revision number is not in the general case, possible. (hence it is not (always) possible to reconstruct a lost branch tag.) However, given a branch tag name, x, instead of a revision number, then "x.base" may be calculated easily, right? (by using RCS_whatbranch() and then doing what's done at the beginning of RCS_getdatebranch() ) And I think in this case, we'd always have the branch tag..., if I understand John C's proposal right for branchname.base correctly. Alos, I think I mistakenly confused BASE with this "branchname.base"..., as I understand BASE, it refers to the revisions that you originally checked out, whatever they may, without any changes that you've made in your working directory, correct? So If that's correct, then BASE is very different than this "branchname.base" proposal. Maybe we should call it something different, "branchname.fork" or "branchname.origin" or something, (supposing somebody has time to look at doing it. -- steve
Re HEAD (was Re: .trunk patch refinement)
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 branchname.latest - For the latest version on a branch branchname.base - For the version where the branch sprouted (ie. the base from the parent branch) Agree 101%! ;-) (There could be a bit of a chickenegg 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 to maintain repo compatability.) - Allow importing directly to the main branch, get rid of the import branch. I don't like the latter half of this point though. The magic vendor branch is still a major time saver vs. the effort one would have to go through to maintain local changes on a "normal" branch if the trunk is the vendor's branch (i.e. re-branching as well as re-merging after every import). It would also be more error prone to have the vendor branch on the default branch -- people would be very likely to check it out and work on it by accident. A thought... Could it be that the vendor branch works so well because 'cvs import'-ing sets the 'branch 1.1.1;' field in the RCS header? Whereas 'normal' cvs commands don't (and shouldn't). I vaguely remember something about MKS RCS not correctly working out the default branch (i.e HEAD) to commit to because it didn't set the 'branch' field. But I'm going back 6+ years now and it's all hazy! Mike -- Share what you know. Learn what you don't. Mike Little [EMAIL PROTECTED] work: [EMAIL PROTECTED] Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
Re: .trunk patch refinement
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 + CAUTION: the special tag `HEAD' is interpreted by
Stephen + the `cvs diff' command in a different way than it
Stephen + is interpreted by any other cvs command. `cvs diff'
Stephen + takes `-r HEAD' to mean the following, as nearly as
Stephen + I can tell:
Stephen +
Stephen + For `cvs diff', `HEAD' means the most recent revision
Stephen + on the `current branch' (taking into account whatever
Stephen + sticky tags are active in your working directory) unless
Stephen + the particular file being diffed is not present on the
Stephen + branch, in which case the head revision of the trunk is
Stephen + taken. It is evident that there are at least some cases
Stephen + for which this definition fails, that is, the wrong
Stephen + revision may be found by `cvs diff' when used in combination
Stephen + with `-r HEAD'. You may wish to use `.trunk' rather than
Stephen + `HEAD'. The `.trunk' tag acts as a branch tag name for the
Stephen + trunk.
Stephen +
This seems very strange behaviour for diff, and I now understand why
you might want to diff against .trunk. But why does diff work that way?
:!mcr!:| Solidum Systems Corporation, http://www.solidum.com
Michael Richardson | In DENVER.
Personal: A
HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html"[EMAIL PROTECTED]/A.
PGP key available.
Corporate: A HREF="mailto:[EMAIL PROTECTED]"[EMAIL PROTECTED]/A.
RE: .trunk patch refinement
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: snip 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! snip
Re: .trunk patch refinement
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 do this using CVSFile (http://people.freebsd.org/~eivind/CVSFile-0.2.tar.gz) and a small perl script. This would, of course, invalidate any workspaces (checked out copies of the source) presently active. Note that I have not tested CVSFile with repositories that contain 2.x versions, and there may be bugs in CVSFile related to using such repositories - though as long as you don't directly overwrite your original repository, there should be no chance of data corruption. CVSFile lacks documentation - sorry about that. Eivind.
Re: .trunk patch refinement
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 misuse of CVS || at any point. It's worth remembering that a lot of us are using CVS || repositories formed from imported RCS files, and using different rev || numbers with RCS is extremely common. The sccs2rcs script in contrib retains such version numbers when it converts - many of my cvs managed files have version numbers greater than 1 because of this. With sccs, if you use -r9 (or -r99 or -r, whatever number of nines is needed to guarantee that it is bigger than the version number of any file being managed) it is the same as if you had used the current version for each file. I recall hearing that this doesn't work for rcs, but fixing whatever problem there is with this would make -r9 a workable approach. But making .trunk work is a better approach. -- Sleep should not be used as a substitute| John Macdonald for high levels of caffeine -- FPhlyer | [EMAIL PROTECTED]
Re: .trunk patch refinement
"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 (and correct) to say they should not have done that, but the important fact is that it has been done. However the important thing now is to continue to deprecate that practice. Certainly. This does nothing to fix any existing problem. Nor does it help if somebody imports RCS files that have 2.x or higher rev numbers. That includes removing the instructions for doing it from the manual (and replacing them with dire warnings against doing it), and most definitely not adding new code that's expressly designed to handle only one of the corner cases that this sillyness introduces. Um, why not? And what are the other corner cases? If you use the rev number like a cookie, what problems are likely to result? In any case, one of the things we keep saying is never to use the rev numbers, and so you're claiming that the proper way to reference the head is to use the rev numbers? That looks like a kludge to me. So, since a kludge works on repositories that have never had a certain mistaken operation done to them (one that is easy and natural), you're against providing a clean way to handle the problem? (If someone found some way to clean up *all* of the corner cases, and if they could justify the effort this would take even in the face of the design goal of using symbolic tags to identify such things, then that might be a somewhat different matter) Are you saying that there might be a reason to change the rev number to 2.x or so? I don't think so. I think CVS works best, and is likely to continue to work best, when people treat the rev number as a raw identifier for the change. This doesn't mean that it isn't worth handling cases where somebody has previously changed the rev number. 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 It may be possible to renumber the trunk back to "normal", especially if there aren't too many branches in your repository There are too many. You can also leap-frog into a new repository starting fresh with "1.1" at some major milestone in your project. The actual amounts of use of history information is usually far lower than people surmise without measurements and indeed is extremely low if you only examine events where users back past a major milestone. You don't have to 100% cut them off from the old history either -- just keep it in a read-only repository for easy local access and then occasionally audit to see how often it's accessed before you retire it for good. We routinely have to change code that's three or four milestones back, when (for instance) a client runs into a bug. Keeping this code read-only is not acceptable. Further, we consider it important to be able to match source changes with the Gnats PR they are associated with. If we were to change the rev numbers, we'd have to find some way to change them in the PRs. This seems to me a major project to support a particular kludge. Another issue is that we can't invalidate everybody's workspace without major consequences. Most people have projects going pretty much all the time, and there's no time in which everybody's workspace is synchronized with the repository. Forcing such a synchronization is going to be expensive. -- David H. Thornley Software Engineer at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556 at home: (612)-623-0552 or [EMAIL PROTECTED] or http://www.visi.com/~thornley/david/
6-20-2000 .trunk patch refinement
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. The patch applies to the development version of CVS. (and to 1.10.8, with a minor, easily resolved reject in log.c) (I did have some trouble with Larry's 6-19-2000 check-in to server.c, main.c, root.c though, so I ran the tests with those changes backed out.) http://www.geocities.com/dotslashstar/branch_patch.html -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
RE: .trunk patch refinement
[ 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 "sccs2cvs" that would properly translate an SCCS repository into CVS using CVS semanitcs. (I did do this by hand as an experiment once though, at least to see how some of the common cases would be handled, and it worked very easily.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: .trunk patch refinement
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 `-r HEAD' to mean the following, as nearly as + I can tell: + + For `cvs diff', `HEAD' means the most recent revision + on the `current branch' (taking into account whatever + sticky tags are active in your working directory) unless + the particular file being diffed is not present on the + branch, in which case the head revision of the trunk is + taken. It is evident that there are at least some cases + for which this definition fails, that is, the wrong + revision may be found by `cvs diff' when used in combination + with `-r HEAD'. You may wish to use `.trunk' rather than + `HEAD'. The `.trunk' tag acts as a branch tag name for the + trunk. + is not correct nor consistent with this part: /* ! * Special tags. ! * -rHEAD refers to the tip revision on the trunk, _except_ for ! * "cvs diff". "cvs diff" interprets -rHEAD to mean the tip ! * revision of the current branch, however, that behavior is ! * broken, because if the file has not been branched, that is, ! * the revision on the branch is the same one that's on the trunk ! * then the tip revision of the trunk is reported. Also, it's ! * not clear (to me) what happens in the instance of a sticky ! * non-branch tag what -rHEAD is supposed to mean. So, -rHEAD ! * is probably a lost cause, unless you redefine what it means. ! * from cvs.h, which I think is more correct... So I need to fix that. -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
RE: .trunk patch refinement
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 other branches (from the user's perspective, the implementation is rather different.) OK, so exactly how is this 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... ;-) [smc] ".trunk" has the possibility of handling the case where sombody has done "cvs commit -r2 foo", (though I haven't tested that case.) We've had this conversation before, actually, here's part of what we wrote:, (thanks deja.com) Greg Woods wrote: [...: ] It makes me wonder though if a magic pseudo-tag could even be implemented right in the case of bumped release numbers without jumping through a whole lot of hoops. I can't at the moment think of a way to inidicate to RCS that the top of the trunk should be always used without getting the "default branch" stuff involved and messing with that doesn't work well with CVS either since it's effectively reserved for internal use only. [smc] Yeah I think implementing what I want would be pretty hard... But, the changes might be at least localized to the RCS code, excepting any changes needed to handle a tag name that begins with a dot, (i.e. ".trunk" or something as mentioned in the docs. And then I went on to explain that I was "bullheaded enough" to want ".trunk" even though I didn't _need_ it. :-) -- steve
RE: .trunk patch refinement
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... ;-) [smc] ".trunk" has the possibility of handling the case where sombody has done "cvs commit -r2 foo", (though I haven't tested that case.) [smc] I just tried it. echo x x cvs add x cvs commit -m x x cvs tag one x echo 2 x cvs commit -r 2.1 -m x x cvs diff -r one -r1 x (no output, that is, the diffs between rev 1.1 and rev 1.1 ) cvs diff -r one -r.trunk x (you get the diffs between rev 1.1 and rev 2.1) I'll be adding such a case to sanity.sh in my patch later. (Does this justify the effort? who am I to say?) -- steve
RE: .trunk patch refinement
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" patch refinement -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 product was released)? 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 mistaken impression that this use of revision numbers is not the mistake that it is. Rex.
RE: .trunk patch refinement
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.x (presumably when version 3.0 of the product was released)? I don't know for sure -- I never tried it. 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! (Yes, the manual gives instructions on how to do this -- it should not.) [smc] Other than perhaps to say, "don't do that." However, just because you shouldn't doesn't mean nobody will, if only out of ignorance, or by a typing accident, and pretty much anyone with commit access may do this, and once it's done, then what? Manually edit the RCS files to fix it? Abandon the repository in frustration and refuse to work with such idiots? This latter is more or less what you propose CVS should (continue to) do ;-) at least in the area of having a way to refer to the trunk other than a fresh checkout. There are at least a couple ways this can happen, one is "cvs commit -r" and another is copying in RCS files from someplace else. (The latter is the world I come from, so I've got lots of RCS files with weird revision numbers.) Sure, you may certainly say, "sorry, too bad, go away", but that's not what _I'm_ going to say. I will however concede that this ".trunk" feature is for me only a "nice-to-have" and not a "need-to-have", I've lived without it for 3 years now, and others have dealt with its absence for considerably longer than that. And as it happens our current development process involves committing to the trunk only rarely, when a branch is merged to the trunk. It's just something that's always bugged me that HEAD was so weirdly implemented and this "-r1" isn't obvious to anyone and only works by a quirk of RCS and then only under a limited set of circumstances, and when it doesn't work, it doesn't TELL you that it's not working so you easily might fail to notice that you'd generated the wrong diffs or whatever. (or the other probably more correct interpretation, -r1 works perfectly, if that's not what you wanted, well, sorry..) I would be interested in knowing about any other "corner cases" I might run into with my mal-formed repository that you might be aware of. -- steve
RE: .trunk patch refinement
-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 product was released)? 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 mistaken impression that this use of revision numbers is not the mistake that it is. 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. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerPhone: (604) 872-6676 TGI TechnologiesWeb:http://www.tgivan.com/
Re: .trunk patch refinement
[ 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 important fact is that it has been done. However the important thing now is to continue to deprecate that practice. That includes removing the instructions for doing it from the manual (and replacing them with dire warnings against doing it), and most definitely not adding new code that's expressly designed to handle only one of the corner cases that this sillyness introduces. (If someone found some way to clean up *all* of the corner cases, and if they could justify the effort this would take even in the face of the design goal of using symbolic tags to identify such things, then that might be a somewhat different matter) 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. This has doubtless happened to many admins; either they inherited such a repository, or they created the problem themselves while not knowing better. It may be possible to renumber the trunk back to "normal", especially if there aren't too many branches in your repository 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. You can also leap-frog into a new repository starting fresh with "1.1" at some major milestone in your project. The actual amounts of use of history information is usually far lower than people surmise without measurements and indeed is extremely low if you only examine events where users back past a major milestone. You don't have to 100% cut them off from the old history either -- just keep it in a read-only repository for easy local access and then occasionally audit to see how often it's accessed before you retire it for good. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: .trunk patch refinement
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 remembering that a lot of us are using CVS repositories formed from imported RCS files, and using different rev numbers with RCS is extremely common. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: .trunk patch refinement
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 should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! ... I wasn't aware that it's actively dangerous, as Greg seems to be saying. If so, is there any reason to keep it? Why not just make commit's -r option go away? [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ] 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 was released)? "say -r1 when you mean latest-on-trunk" is a kludge, to work around the lack of ".trunk". That it fails on trunk revision 2.x isn't a corner case in CVS; it's a limitation of the kludge. The man's offering to obviate this kludge with a correct solution; what's all the grumbling about? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
RE: .trunk patch refinement
[ 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 was released)? I don't know for sure -- I never tried it. 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! (Yes, the manual gives instructions on how to do this -- it should not.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
RE: .trunk patch refinement
-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 (-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's perspective, the implementation is rather different.) OK, so exactly how is this 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... ;-) 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 was released)? Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
.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's perspective, the implementation is rather different.) You can also find this here: http://www.geocities.com/dotslashstar/branch_patch.html From HACKING: * Writing patches (strategy) [...] For features, the desirable attributes are that the need is clear and that they fit nicely into the architecture of CVS. Is it worth the cost (in terms of complexity or any other tradeoffs involved)? Are there better solutions? I'm not sure I know the answers to the above..., but you can have a look at my code and ponder it. If the design is not yet clear (which is true of most features), then the design is likely to benefit from more work and community input. Yes please, input could be nice. Make a list of issues, or write documentation including rationales for how one would use the feature. Discuss it with coworkers, a newsgroup, or a mailing list, and see what other people think. This has been discussed several times in the past...with no real outcome. Distribute some experimental patches and see what people think. The intention is arrive at some kind of rough community consensus before changing the "official" CVS. Features like zlib, encryption, and the RCS library have benefitted from this process in the past. So far: ...silence... (the sound of crickets chirping maybe) If longstanding CVS behavior, that people may be relying on, is clearly deficient, it can be changed, but only slowly and carefully. For example, the global -q option was introduced in CVS 1.3 but the command -q options, which the global -q replaced, were not removed until CVS 1.6. I have carefully refrained from disturbing the longstanding (but disturbing) behavior of the "HEAD" pseudo tag. * Writing patches (tactics) When you first distribute a patch it may be suitable to just put forth a rough patch, or even just an idea. But before the end of the process the following should exist: Check! - ChangeLog entry (see the GNU coding standards for details). Check! - Changes to the NEWS file and cvs.texinfo, if the change is a user-visible change worth mentioning. Check! - Somewhere, a description of what the patch fixes (often in comments in the code, or maybe the ChangeLog or documentation). Check! - Most of the time, a test case (see TESTS). It can be quite frustrating to fix a bug only to see it reappear later, and adding the case to the testsuite, where feasible, solves this and other problems. Check! Include words like "I grant permission to distribute this patch under the terms of the GNU Public License" with your patch. By sending a patch to [EMAIL PROTECTED], you implicitly grant this permission. Check! "I hereby grant permission to distribute this patch under the terms of the GNU Public License" -- Steve Cameron So, of course my expectations are not that this will be checked in, but maybe someone will point me to what I need to fix to move things in that direction, or tell me not to bother. Thanks, -- steve The patch is attached. Or you can get it here too: http://www.geocities.com/dotslashstar/branch_patch.html __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ Index: NEWS === RCS file: /home2/cvsroot/ccvs/NEWS,v retrieving revision 1.79 diff -c -r1.79 NEWS *** NEWS2000/05/05 14:48:37 1.79 --- NEWS2000/06/18 04:19:30 *** *** 1,5 --- 1,8 Changes since 1.10: + * New ".trunk" pseudo-branch-tag added which acts just like a branch + tag, but means the trunk. + * The "cvs history" command output format has changed -- the date now includes the year and is given is ISO 8601 format (-mm-dd). Index: doc/ChangeLog === RCS file: /home2/cvsroot/ccvs/doc/ChangeLog,v retrieving revision 1.622 diff -c -r1.622 ChangeLog *** ChangeLog 2000/06/14 17:41:56 1.622 --- ChangeLog 2000/06/18 04:19:47 *** *** 1,3 --- 1,7 + 2000-06-18 Stephen Cameron [EMAIL PROTECTED] + + * cvs.texinfo: Document new ".trunk" pseudo branch tag. + 2000-04-03 Pavel Roskin [EMAIL PROTECTED] * cvs.texinfo (Telling CVS to notify you): Remove backslashes Index: doc/cvs.texinfo === RCS file: /home2/cvsroot/ccvs/doc/cvs.texinfo,v retrieving revision 1.489 diff -c -r1.489 cvs.texinfo *** cvs.texinfo 2000/06/14 17:41:56
