apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: httpd-2.0/apr/apr-util Code Freeze
Date Mon, 12 Mar 2001 13:52:47 GMT
> > > _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 <lkcl@samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."


Mime
View raw message