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.
Matt Schuckmann Wrote: > > By using the floating branch tag we almost get the best of both worlds > > 1. The developers new code is kept issolated on the branch and the branch is > > really only those changes made by the developer. > > 2. The developers get the lastest stable code from the release code line > > whenever they update thier sandbox. > > The only thing they don't get is any changes made on the release code line > > in files they have modified on the branch, to get those changes they must do > > an explicit merge from the parent to the branch. > > > > I guess what I really want is a floating branch tag that only floats when > > you merge the parent onto the branch, that sounds a little more usefull than > > the way it's implimented now, it sort of prevents unexpected breaking and it > > helps to keep the task branch to purely task releated changes. What do you > > think? > > Glen Starrett Wrote: > That's essentially what mergepoints do for you, and what makes them so > valuable. Then the developer decides when to get the latest -- gives > them the control (OK, they have control over when they do an update, but > I often update in order to reset accidental changes or other reasons). > I don't quite see your point. Mergepoints just tell you when a revision was created as a result of a merge and where that merge came from, right? I'm interested in preventing revisions from occurring on a branch on files that otherwise wouldn't have branch revisions because that file doesn't have any changes specific to the Task that branches is associated with. Is that clear, it's kind of tough to explain, this is a place where a picture would be worth .... Say you have a.cpp with a branch tag but no revisions a.cpp 1.1 - - - BR1 | | 1.2 And you do an explicit merge of HEAD into BR1 (cvs up -kk -j HEAD) a.cpp 1.1 - - - - - BR1 | | | | 1.2 -----> 1.1.2.1 Now you have 1.1.2.1 which is just a copy of 1.2. It would be nice if you had the option for the merge to just move BR1 to 1.2 instead.This is in essence what floating branches are supposed to do except they do it implicitly and it might be better if they did it explicitly (i.e. via a merge command with maybe a special option or something) I suppose that you could infer that a file has no changes associated with a task if all the revisions on that Task's branch are the result of merges from the parent (identified by mergepoints) but that could get a little confusing and would require some sort of special script. On a side note I've done some testing of floating branches and they sorta kinda work. They don't seem to quite work right when you apply a floating branch to a branch or a floating branch to a floating branch. Also the rtag command doesn't recognize the -M option, although "cvs -H rtag" says that it should. I can post a new thread detailing the problems I found. Plus it also appears that WinCVS, ViewCVS, and CVSGraph all don't know how to deal with them. I was testing with CVSNT 2.5.01 (Travis) Build 1927 Matt S.