> > > _however_ :) > > Saw that coming :-) oh, darn :) > > > once you _get_ to the point where cvs main is > > > always-releasable, then using this multi-tag process could help make cvs > > > main _remain_ always-releasable. > > We only need it releasable when we want to release :-) > > Seriously, the general policy is "do your best to keep it compiling and > working, but we understand that sometimes things simply break." We have > about a half dozen active committers, and things tend to work out fine (no > stepping on toes). We haven't really need any long term branching, but I do > know a couple cases where it would have been nice.
... i've worked in long-term branches. i do not recommend it. > > > for, as you described - some significant modifications to mod_include > > > could be done in a dev_mod_include_rewrite tag, and only when completed > > > are they cvs merged into cvs main. > > > > > > surely that's not too much process to cause more pain than the benefits > > > are worth, neh? > > It actually has some pretty big pain because of the merge problem. CVS has > horrible merging issues :-). Let's say that you had to grab some stuff from > HEAD and pull it into dev_mod_include_rewrite. Say, because some of the code > *around* you has changed, so you need the compensating changes from HEAD > into your branch. > Later on, you go to merge a reasonable stable form of the branch back into > HEAD, but all those bits you pulled over get reapplied back to HEAD, > generating a bunch of conflicts. You bitch, fix them, then check in the new > HEAD. > You continue some more work on the branch. You're finally done, so you go to > merge it back onto HEAD. Now you're really screwed. Pretty much the entire > set of changes causes conflicts because CVS doesn't record that you already > merged a good portion of the branch onto the HEAD. > > It is a pain in the ass. yep. and that is why i do not advocate the use of full branching. when this is extended to a whole bunch of files over a prolonged period of time, the risks of these kinds of conflicts goes beyond acceptable limits. the "partial tagging" is therefore a recommended method to help avoid exactly this nightmare scenario. the scenario you describe would tend to imply the following things: 1) a different developer is responsible for the file mentioned, under both versions (HEAD and the hypothetical/example dev_mod_include_rewrite), where the two developers are not coordinating on modifications to the same file. 2) the file contains such different functionality that different developers, over long periods of time, tend to modify it for different purposes. this implies that the file should really be broken into two separate files, and one of those files will be partially tagged, and the other will not. i describe this in the article, already. the point of the partial tag is that is targetted at a specific development area, allowing all other area to remain "current" instead of "static" [i.e. from the time of the "full" branch, which we already know is a bad idea]. the need to do cross-merging, if it can be avoided, means that at the end of the partial-tag's lifetime, you can do this, in cvs main: cvs update -j "partial_tag_name". and _that's it_. i suspect that this may even work even if you have performed modifications in the same files, and you make _Absolutely_ sure that the overlapping areas are identical (including whitespace). then, cvs will detect that you already have those changes and will reject them "cleanly". which will leave you only with the conflict areas to resolve which you will actually _genuinely_ need to resolve, not spurious ones. e.g. whilst writing a new version of apr_pool.c, someone also decided to fix a bug in hte cvs main apr_pool.c, or added an extra argument to one of the apr_pool.c functions and so did you, but they were different arguments. now, the intersting thing about this particular example is that this simply would not occur [okay, it might: see below]. why? because when someone added an extra argument to a function in the apr_pool.c code in cvs main's apr_pool.c, they would start to modify all usages of this function, right? now, assuming that the apr_pool_tagger_developer has not partial-tagged all of the same files [which he probably would, if adding an extra but different argument, as well, to the same function] then once the cvs main commit had occurred, then he would pick up all of these cvs main files on his next cvs update, and his partial-tag build would break. _that's_ the whole point of doing partial tagging: to catch things in this way. so that the tag-developer can stay current with everything-else. and if that means a little bit of pain for just a few files, then so be it, that's far better than a _lot_ of pain at the end of a merge! and you most certainly would _not_ catch this with full tagging, which is why i am so against full tagging, myself. > Personally, I'd just state that we don't worry about the problem. Subversion > has *very* easy branching. ah, yes. i almost forgot. sbv is using apr :) hi people, hope you're taking this stuff on-board: i really hope that you can help avoid the nasties of full branching :) all best, luke ----- Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> ----- "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..."
