Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: > If you can change a tag it's a branch... A tag specifies a single revision > only, as that's it's purpose. You can move tags (although that should be done > as little as possible), but they can't hold more than one revision. I know that tags are mostly used to specify a release/revision of the system as it was at some specific time. But there are no technical obstacles to use the tags differently. And that's what I'm suggesting here, a little more flexible usage of the branches and tags. I dont want a single tag to hold multiple revisions (altough i dont even know what you mean by that), I just want a little more flexible way to use the tags. > If you want to commit a change to several branches that's what merging is > for... There isn't another practical way to do it other than the way it's > done now, because you're dealing with different code & have to merge > differently in each branch (with possible conflict resolution). I'm not talking about situations where you commit changes to different branches. I'm talking about commiting a change to multiple releases/revisions. And specifically about situations where the file revision does not need to be different in the different releases. I try to lay out a new example here. There is one file A in the repository, and a need for three different releases, R1, R2, R3. How we would do it today: Create branches b_R1, b_R2, b_R3 edit file A in b_R1. merge change to branches b_R2 and b_R3 (Now we have three different, but identical revisions (plus the original) now edit A again in b_R1. This is a change we want only to be in b_R1, so we wont merge it anywhere and finally edit A in b_R2, and merge to b_R3 (Now we have three different revisions, of which two are identical (plus previous revisions)) How I would like to do it: Create commitable Tags ct_R1, ct_R2, ct_R3 edit the file A in the ct_R1 (meaning that I have checked out ct_R1, the file actually resides in the main trunk) update tags ct_r2 and ct_R3 to point to the same revisoin as ct_R1 does. (Now we have single revision with three tags pointing to it (plus the original revision)) now edit A again in ct_R1 This is a change we want only to be in ct_R1, so we wont do anything else now. and then we edit A in ct_R2. Now if we try to commit it, we cannot do it, since ct_R2 is now outdated. Now we need to branch the A to b_R2 and commit the change there. Also because we want the change to ct_R3, we update the ct_R3 to point to the b_R2 revision. (Now we have two revisions with two tags pointing to one and one tag pointing to the other) I know the philosophy how to use the branches and the tags differs from the traditional way, but technically it does not differ that much. I would still use branches as branches, but the difference is that the branches are created only when needed, not when one file out of the whole bunch needs the branch. I think that the basic implementation in code wise is also very simple. When commiting, instead of checking is the sticky tag branch: if (status == T_MODIFIED && vers->tag && !RCS_isbranch (finfo->rcs, vers->tag)) we could check if it is a branch OR a writable tag. Of course there are some other modifications needed also, e.g. when creating the tag, the information needs to be stored that the tag is a writable tag. But that is pretty much it what is needed in the basic implementation. Some additional nice-to-have features could be something like "update writable tag", which could move the writable tag to the leaf revision of the branch the file is in (if there is no branchpoints in between). Hope this illustrated the idea a little further, Tuomas