httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p...@originative.co.uk>
Subject Re: 2.0 header file rearrangement
Date Sat, 18 Mar 2000 12:54:16 GMT
"Roy T. Fielding" wrote:
> 
> > One thing that Ryan and I've discussed is for us to start _really_
> > utilizing the power of CVS. Things like branches and tags. Up
> > to now we've "resisted" any but the most basic functions, but
> > we should really start taking full advantage of what CVS give us.
> 
> My experiences with CVS branches (aside from the vendor branch) have
> all been negative.  All it does is mess up the logs.  It is generally
> more effective to just tag and copy the repository, particularly since
> that allows you to do widespread experimental deletes/moves without
> trashing the main branch until you merge the finished bits.
> 
> If anyone would like to fix CVS branch behavior, a good start would be
> to linearize the changelog when two branches are merged, thus making
> the log entries appear sequential according to when they were added
> the the main branch.

That's just not feasible. You're assuming that the two branches are
moving in sync so that changes that were made on one branch will slot in
to the development that took place on the other.

Generally, a branch is used when the code forks and when you merge
something from one to the other you the changes made on one branch have
no relevance to the way the code looks in the other branch.

I can't see any useful purpose to having the log messages from one
branch merged into the other in any case. The log message should reflect
the change being made by the commit. If you're merging code over from
another branch then the log message for that merge commit should be say
all that needs to be said for that particular code change.

The problem with tagging and copying is that you have to have access to
*all* the repositories to be able to view all branches and all log
information. Even branching the tree once will mean double the download
and storage, if you branch once every release then you have a total
mess. It's also impossible to view changes between versions if they are
stored in different repositories, whereas if something breaks in one
branch but is still working in the other CVS is very useful for finding
our what the changes were between the two. 

FreeBSD has used branches since day one and we've found them invaluable
rather than a problem. That's not to say that a branched repositury
isn't more complicated to maintain but the extra skills needed are only
required by those working on multiple branches and the repository admin.
Developers working on the head branch would see no difference.

Paul.

Mime
View raw message