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.
Tuomas Huhtanen wrote: > 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 OK, so a writable tag is just a branch tag, and you want the ability to slide the branchpoint forward along its parent branch, provided no revisions have been comitted on the branch yet? Does this actually gain you anything except slightly smaller repository files? Max.