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: > On Mon, 28 Apr 2003 16:46:27 +0100, "Max Bowsher" <maxb at ukf.net> wrote: > > >>Tony Hoyle wrote: >> >>>On Mon, 28 Apr 2003 15:47:10 +0300, Tuomas Huhtanen >>><tuomas.huhtanen at vertex.fi> wrote: >>> >>> >>>>But as Tony suggested, the -f might work for you in this case. The only >>>>thing is that once you have checked it out with some branch, it stays >>>>there unless you take a clean checkout again. So if for example you have >>>> created a branched document, check it out, then later modify the main >>>>document so that there is no need for the branch doc, the -f scheme >>>>would not work. The writable tag would recover that situation just fine. >>> >>>No it wouldn't - once you've branched you can't 'un branch' because that >>>would be changing history. >> >>You can't unbranch, but you can set the writable tag back to the parent >>branch. >> > > That's different - it's just moving a tag.. you can do that already. That's > not what is being said above - it's saying if you make a document that is the > same as the root the branch tag magically disappears, which isn't practical > (it's also pointless - it saves you zero effort and is very counterintuitive). > > Basically, writable tags are branches, and I've yet to see any justification > for trying to confuse the issue by changing the definition of 'tag' to mean > 'branch'. They're for separate things, and should be kept so. Actually Max got it just right. You would just set the writable tag to point to the branch you like. So that part is just the traditional moving a tag. I didn't say anyting about magically appearing or disappearing tags. And remember, I'm talking about tags, not branches. The _only_ thing I'm talking about here is to be able to commit with a certain special sticky tag. I could do that today for example with python macro in winCVS. In that case, the procedure would be something like: 0) You have checked out files with some sticky tag (e.g. ct_R1), and are about to commit the changes made to the files. 1) Extract the revision number of file to be commited. (e.g 1.1.2.2) 2) Extract the branch number from the revision number (e.g 1.1.2) 3) Force commit to the branch number (1.1.2) 4) Move the tag to the new revision (ct_R1->1.1.2.3) 5) Update the local copy to the moved tag This would do it, but not atomically of course. The other thing is that then I'm bound to specific client of cvs. And third, that would be quite slow. Tuomas