Re: adding on branch

Paul Edwards <[email protected]> wrote:

> [ import of a file already added on a branch ]
>
> In this case, a dead 1.1 should be treated EXACTLY THE SAME
> as a non-existent file, and import should bring it to life and take it
> out of the Attic and it should look identical to all its siblings which
> are being imported in the same command, and behave just the same
> as them too.  CVS should not behave differently just because some
> joker got in first (on his own branch).

But an import is just a first step.  There is a mandatory second step,
to fix your trunk:

    cvs checkout -j previous_import -j this_import project

The sandbox has your new file in a "cvs added" state.  When you
commit, it will create a live revision 1.2 on the trunk (and yank the
repository file out of the Attic).

In general you MUST do this merge, fix any conflicts and commit.
Until then, your trunk is broken.  For safety, it's best to tag before
the import and after the crucial commit.  So in more detail,

    cvs rtag -F pre_import project
    (go do the import)
    cvs checkout -j previous_import -j this_import project
    cd project
    (fix the mess)
    cvs commit
    cvs tag this_import_postmerge

If the merge is hairy and you can't do the commit for a while,
you have the option of branching off "pre_import" to continue work while
you figure this out.  When you do, you merge and close the branch.


> It is not logical for files that are meant to be safely off on a branch,
> to interfere with the import process.

They don't, if you finish the process.


> [ ... ]
> We are not the master site, we are in Australia.  The master is in
> the USA.

> USA sends us their official drop, and that is imported.  They
> actually maintain multiple independently maintained releases, so
> it is imported with a specific branch number:

> cvs import -b 1.1.325 etc release-3_2-v1

Ow.  Multiple vendor branches.  You're asking for trouble.


> Then we have 2 different projects in Sydney, so it was branched at
> this stage:

> cvs rtag -r release-3_2-v1 -b avs-3_2 proj
> cvs rtag -r release-3_2-v1 -b dbbe-3_2 proj

I see.  You use no trunk.  That breaks your imports.


> Developers on the dbbe-3_2 happily muck around, create a couple
> of new files too.

> It is shipped to USA with:

> cvs rdiff -r release-3_2-v1 -r dbbe-3_2-v5

> USA adds their own stuff, and eventually we get a release-3_2-v2 back.

> Every file in release-3_2-v2 is as official as it gets.  This is the master.
> The head should not be dead, these are all active files.  The fact that
> the dbbe-3_2 branch was the first to add them, is no longer of any
> importance.  The official release has arrived, and will be used for
> all projects.  It should not be treated as a pariah, with a dead head
> and relegated to the Attic.

You let out a potential show-stopper when you said

    They actually maintain multiple independently maintained releases

because that in itself wrecks the import assumptions.  There may be a way
out, though.  Assume for a moment that they start shipping you a linear
sequence of releases.  Then you could import, fix your trunk as above,
and re-graft your branches to the new tip of the trunk.

    cvs update -A	: should be == release-3_2_v2_postmerge
    cvs tag -b avs-3_2_v2
    cvs update -r avs-3_2_v2
    cvs update -j release-3_2 -j avs-3_2
    (fix conflicts, there will be some)
    cvs commit

Now you abandon branch avs-3_2 and resume on avs-3_2_v2.  Similarly
for ddbe-3_2 and dbbe-3_2_v2 .  At least that's one way to do it.

Now about the part where they ship you updates to multiple codelines.
Your group doesn't perform merges across codelines, does it?  It seems
to me that you take one of the codelines, branch it off for a specific
task, and send patches.  If so, you could very well treat each
codeline as a separate CVS module, with a unique trunk.  Import will
then work as designed.  Also, since all your work is on branches, your
post-import trunk merges will be trivial.  In fact, all they will do is
catch the file-created-on-a-branch case that is bogging you down
today.

Your process with multiple vendor branches almost works, but only
because you don't use the trunk, and that in turn prevents you from
managing added files cleanly.


> [ . . . ]
> cvs checkout -r dbbe-3_2 proj
> cd proj
> cvs update -d -j release-3_2-v1 -j release-3_2-v2

> I get an error saying "file.c has been added in dbbe-3_2".  I

I get that error if I try the equivalent of

    cvs update -r ddbe-3_2v2
    cvs update -j ddbe-3_2

but if I do

    cvs update -r ddbe-3_2v2
    cvs update -j release-3_2 -j ddbe-3_2

the merge occurs and I have to check for conflicts, as you want.


I'm not sure if this belongs in gnu.cvs.bug, because of the way you do
your imports, the multiple vendor branches especially.  Maybe
gnu.cvs.help, but probably better in gnu.cvs.help.deep.sorcery .