[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Is this feasible: Trunk files that update branches also

From: Thornley, David
Subject: RE: Is this feasible: Trunk files that update branches also
Date: Wed, 7 Nov 2001 11:29:41 -0600

> -----Original Message-----
> From: Tobias Frech [mailto:address@hidden
> Sent: Wednesday, November 07, 2001 1:43 AM
> To: address@hidden
> Subject: Is this feasible: Trunk files that update branches also
> Hi!
> How to implement our strategy with cvs (see below) ?
> I searched through the archives but couldn't find any answer to my
> question. Also my tests returned only negative results so far. This is
> why I am trying to get an answer here:
> What we want to do is have a main trunk of source code. The 
> source code
> consists of some documentation files (DocBook/XML) and a build system
> for them (-> HTML,PDF). As we have different releases of the 
> software we
> would like to "split" the manual in different versions. The easy way
> would be to branch and tag the whole stuff and have a totally separate
> branch from the main trunk.
What do you mean by different releases?

How we do it is that, when we are ready to call what's on the main
trunk a release (i.e., it has the functionality it needs), we cut a
release branch.  It's generally not ready to ship yet, so people
keep working on that release branch while other people work on new
stuff for the next release.  All changes are merged to the trunk and
to applicable other branches.  Merging is done forward only, so that
a change to release_3 needs to be merged to release_4 and the trunk.
If a customer wants a new feature, they can upgrade to a new release.

This works well for us.  If you have different releases for different
platforms, say, so you're trying to upgrade functionality in several
different releases, then CVS branches are not what you want.

> This is a bad idea for documentation and the build system in 
> my eyes. We
> have several occasional docu contributors. You can write it a dozen
> times everywhere: "If you update the branch or the trunk, please check
> if your change also applies to the other part". People won't notice or
> read it.

We have few problems with that.  We keep the branches to be changed
in the checkin process, and provide scripts to make the merging easier.
I think what makes the difference is explicitly listing the branches the
change is to be put into.  Alternatively, it could be establishing it
firmly as part of the checkin procedure.

 Improvemnts on one part get lost for the other part because
> people don't apply it to both (or with two branches: all three) parts.
> So the idea is to have the build system and all the docu files in the
> main trunk. The branches ONLY contain some "older" versions, which may
> be also be improved over time (but this time only in this branch). 
I don't see that that's going to work.  Having the build system in the
main trunk, applicable to all branches, locks you in:  if you're
going to change the build system or documentation, then you lose
compatibility with the branches.  If you put static tags and decide that
there are going to be no changes after shipping (which may or may not
be realistic, depending on your customers), it might work.

However, it is awkward to maintain one set of things on the trunk and
another set on a branch.  You have to make sure they're on the
right branch or trunk.  You can check out separate directories separately,
but mixing inside a directory is asking for confusion.

> Now I have this situation:
> cvs checkout -r branch_1 -f docu
> general-intro.xml        from trunk
> first-steps.xml          from trunk
> config.xml               from branch_1
> If I edit config.xml and want to commit it (to branch_1) everything is
> fine. But if I edited first-steps.xml and want to commit it (should go
> to the trunk) then cvs complains about it, because the file 
> is not part
> of branch_1 and cvs "does not get it" that it should commit it to the
> trunk.
CVS has files checked out on the main trunk, a branch, or a version number
or date, and checks into the trunk or branch or not at all.  What is
branch_1 here?  A branch (in which case first-steps.xml gets checked into
that branch with no CVS complaint) or a revision tag (in which case CVS

> You could say, I need to update/co the trunk version then and 
> update on
> this. My experience is that people won't do it. This is why the branch
> stuff is sticky. People don't want to bother about branches and stuff
> all the time. I need some method to commit to the trunk from a branch
> checkout.
Our method is to commit on the branch and merge to the trunk.
This is going to be necessary anyway; in that example, what if config.xml
had an error that had to be corrected there and on the trunk?  If you
make it easy to do, and emphasize that people do it (I suppose having
some sort of formal procedure to follow would help here), my experience
is that people will do it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]