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.
I think you meant this to go to the list, as well as me. Tuomas Huhtanen wrote: > 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? It would be impossible to reliably do a date-based checkout from a commitable tag. Max.