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

[Damian Wiest]

>Message: 7
>Date: Wed, 07 Nov 2001 08:42:36 +0100
>From: Tobias Frech <address@hidden>
>To: address@hidden 
>Subject: Is this feasible: Trunk files that update branches also
>
>[snip]
>
>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.
>
>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. 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). 
>
>This way changes on the build system or general documentation files
>would also be "altered" in the branches, too.  My idea was to have only
>the "different" files for a version in this branch and use the -f option
>on checkout/update to get all the other files from the main trunk.

Sounds like your problem isn't with CVS, it's with the developers not
following the protocol.

If you don't want to branch the entire project for each new release,
but would rather always give the user the latest version of the
manuals, then only branch the directory containing the build
system.  This will resolve your developer problem, but will create
new potential problems since someone could checkout an old release
of the project and get an inaccurate/incorrect manual.

>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.
>
>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.

I've never used the -f option with -r, so I don't know if you're
getting a weird result.  If you do a "cvs status" after the checkout
are all the files the versions you expect them to be?  What do you
mean by CVS complains?  How are you doing your commits; per file or
the whole directory?

If you've checked out a version from one of the branches and now
want to commit the change on the trunk, you could do the following:

   cvs -q up -A first-steps.xml
   cvs -q ci -m ... first-steps.xml

Since first-steps.xml has been modified the update will only remove
the sticky tag, it won't actually update the file to the version on
the trunk.  AFAIK CVS will never allow local changes to be
implicitly lost.

>Perhaps you also have ideas for totally different strategies ?
>
>TIA,
>
>Tobias

I would use the following strategy:

   1. Keep the development versions of the docs and build system
      on the trunk.

   2. When it's nearing time to release a new version, branch the
      project and name it something like release_X_Y.

   3. When you actually release the project on the release_X_Y
      branch, stamp the branch with a regular tag called something
      like release_X_Y-20011108.

   4. Explain to the developers that if they're making changes to
      an old release of the project, they need to work on that
      branch; and if necessary, merge their changes back into the
      trunk.

   5. Write up formal, step-by-step protocols for making these
      types of changes.  Distribute to the developers and explain
      why it's important that they follow the protocols.

   6. Enforce the strategy, rolling back commits as necessary.

I'm assuming that you have the authority to enforce your decisions.

HTH,

-Damian