Re: adding on branch

[Paul Edwards]

"Pierre Asselin" <pa@invalid.invalid> wrote in message 
news:9jv8bb.152.ln@brick.verano.sba.ca.us...
> Paul Edwards <kerravon@nosppaam.w3.to> 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).

Ok.  But for whatever reason, that second step is not mandatory
for people working on the trunk.  You could argue that they are
just lucky and get away with it.

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

Ok, if you make this argument, then the trunk is broken.

But if you make that argument, you should change the
behaviour of import - it shouldn't interfere with the head
at all until the user is ready to do a merge.  Maybe he has
no intention of using the imported version.  Maybe he wants
to import the latest greatest version of ccvs, but only start
using it (on the head) if he has tested it and it works.

In some places, a new file with extension of ".c" will be
automatically compiled by the Makefile, so a new file
should not be active on the head until it is really ready.

import should not break the head.

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

This is a workaround to what is probably a design error.

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

If you define it that way, then you're replacing one design error with
another design error.

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

That's nothing.  I am starting to get USA to unofficially take
projects from us and import them into CVS as a precursor to
committing them to PVCS.

In order to do that, Sydney's projects are going in on a vendor
branch their end, plus there's the main release-3_2 vendor branch,
plus there's a pvcs-3_2 as another vendor branch which represents
the latest extraction from PVCS.

There is only one "normal" branch, which merges all these
things together (into an america-3_2 equivalent), which is then
exported and used to go into PVCS.

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

Nominally there is a head, we use that for local hacks required
to make it run on our system, but not project-related so aren't
meant to be shipped.

At the end of the day, I could live with the strangeness of
the files being in the Attic if cvs didn't have any weird problems
due to that.  Given that I don't have any reproducible weird
problems to hand, you could argue that there are no known bugs
with files living in the Attic (in which case I would prefer all
my files were in the Attic, why do only ones that I branch in
advance get to go there?), and this is freedom of implementation.

Fine.  The one that I can't accept is when I do a join onto the
branch I get a "file exists but has been added on branch ...",
but no conflict is created to force me to resolve it before
committing, and no markup showing the differences either.

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

Yes, this would also work, but I don't want to tell the programmers
to abandon their branch every week.  We get a new shipment from
USA every week when the product is being actively tested.

Instead, I want programmers to think that their branch is king, and
we get some minor bugfixes from USA every week, and the
procedure they follow is the same as when one of their
colleagues makes a change.

> 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

Yes it does.  While waiting for them to get their act together
with release-3_2, we started developing avs-3_1 off release-3_1
instead.  Now we have both avs-3_2 and avs-3_1.  Development
is done on avs-3_1 as it is a stable environment and the database
is correctly set up.

Periodically I merge the latest avs-3_1 development onto avs-3_2
for shipping to USA.

BTW, if you think any of this is bad, try to imagine the manual
process that existed before I rocked up and risked my job by
installing CVS so that I could actually do the job properly
instead of relying on me to manually merge a hundred files
every week perfectly.  I figured my job was less at risk if I
could do the code merge well instead of making regular
mistakes.  The gamble appears to have paid off.  Zero code
merge problems from Sydney since I arrived.  Still plenty of
problems from the USA side though.  But it is changing.

> to me that you take one of the codelines, branch it off for a specific
> task,

It's not a specific task, it is an ongoing project, that takes
months to complete.  They don't particularly like other projects
disturbing their sandbox and creating headaches for them, but
it has to be done!

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

I'm not really being bogged down by that.  And this will
produce the same error.

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

It isn't this that is the worst problem.  That problem would still
exist.  Most of all it is the branches that I want updated cleanly
from the import.

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

That would be dangerous if I did that.  I would lose all the
changes that release-3_2 made when it added its version of the
file, and unconditionally replace them with the dbbe-3_2 version.

In actual fact, that's the situation I already face.  I lose
release-3_2 changes.  I have already been bitten by that and
I have already changed my procedure to search for "has been
added".  Unfortunately the time pressures are such that I am
multitasking and can forget this step and it doesn't failsafe.
And the words I am dreading is "this problem was created
by your use of unauthorized software - we have an existing
procedure (yeah, manual and error-prone - ed) which you
were supposed to be following".

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

I wasn't sure if the latter was a joke, so I did a google search to
confirm that it is either a joke or an obscure newsgroup.  :-)

Anyway, I agree with your general principle that the second
step is mandatory, and in fact, I always do that second step
regardless, so this is not my main problem and I won't benefit
from the fundamental design change that is currently being
contemplated, so given that no-one else appears to have an
issue with that, that should probably be deferred to another day.

BFN.  Paul.