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.
Max Bowsher wrote: > OK, just as a summary: > > Commitable tags are a kind of just-in-time branching, the idea being to > avoid the need to branch and then repeatedly merge when multiple lines of > development share the same file but are very unlikely to change it. (An > example: a new feature being developed in a complex project - only a subset > of files will contain actual changes, the rest only redundant copies of the > trunk changes, as they are merged into the branch). Yes, the idea is to be able to do just-in-time branching. But there is more than just the just-in-time branching. There comes a bunch of implicit features along. One aspect is that the developer cannot commit to a commitable tag if there is new revisions made to the file after the tag has been last updated (because the tag is not anymore in the leaf revision). So that forces the developer to make the "merging"(updating the tag/creating a branch) decision as early as possible. (It would be identical to the situation where developer tries to commit his changes to outdated revision) One aspect is that you would get visual hints about how close the different releases are to each others, because the tags point to the same revision, not different but identical revisions. Even if they would not point to the same revision, the tags would still be close to each other. One aspect is that the codebase would become kind of self organizing to logical modules (in version sense). Since you wouldn't create branches to files you dont need to branch, they remain in the last needed "module branch". But yes, the biggest plus is the ability to create branches only when needed. > The huge drawback is that you lose history tracking of the correllation > between files merely accepting trunk changes and those actually being > modified on the branch. I'm not sure I understand what you are saying here. Care to elaborate? Tuomas > The co/up -f flag is a _partial_ solution to this kind of problem, but would > need to be made sticky, amongst other changes. > > > I believe that the true answer to this problem is to simply merge regularly. > (And perhaps implement some kind of extension to the RCS file format so that > a revision can say "I have no changetext of my own, I am exactly equal to > <revnum>".) > > > Max. >