Re: adding on branch

[Paul Edwards]

"Max Bowsher" <maxb@ukf.net> wrote in message 
news:mailman.6835.1054044771.21513.bug-cvs@gnu.org...
> Paul Edwards wrote:
> > "Max Bowsher" <maxb@ukf.net> wrote in message
> >> Except the natural behaviour of an import is to add revisions to the
> vendor
> >> branch, and create a head revision to start from *if and only if* one
> does
> >> not exist already. If there is *any* existing head development,
> >
> > But that's the whole point - there is no existing head development.
> > All there is is a user mucking around on his own branch, which is
> > what people with their own branch tend to do.  A user mucking
> > around on his branch should not interfere with what is essentially
> > "production processing".
>
> Adding a file on a branch *MUST* (due to the nature of the RCS file format)
> add a head revision. Since the head revision is simply a placeholder, it is
> marked dead.

Ok, I've just confirmed that behaviour.

> Likewise, importing a new file *MUST* (again, due to the RCS file format)
> add a head revision.
> Since the normal case is to develop from here, this revision is live.

That's fine.

> >> import
> >> simply shows a conflict, and expects you to do a merge.
> >
> > I don't mind the conflict.  But I won't notice it either way.  There
> > entire source tree shows up as a conflict whenever I do an
> > import, because almost every single file exists, and has half a
> > dozen branches on it.
> >
> > I do mind having to do a merge to get the head made active.
> > I didn't even realise I could do that.  I thought I needed to
> > manually move it out of the Attic to get a head "created"?
>
> Manually muck around in the repository? Why does the internal structure of
> the repository bother you so much?

Two reasons:

1. It's a sign of inconsistent and incorrect behaviour.

2. I've had problems with normal operation because of annoying
files in the Attic.

> > I don't want to manually merge all these files anyway, I want
> > to be able to say "yes, yes, yes, all those imported files, make
> > them active, regardless of what some tinpot branch owner
> > has been up to".
>
> CVS has no such command, because that's not what import is intended to do.

It is exactly what is required for normal development.

> >> The rule is simple: "head is dead" == "in Attic".
> >> The fact that 2 files came from the same import is irrelevant.
> >
> > I think existing behaviour is illogical, and requires manual
> > processing for no reason.
>
> The existing behaviour is quite logical. It only seems odd to you because:
>
> 1) You are using import in a way it was not designed for.

It comes very very close to working properly.

> 2) You care a lot about how the internal structure of the repository looks
> like.

I care about inconsistent behaviour.

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

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

I'm not sure what development procedure you have in mind, but
here's how it works the way I have it set up.  CVS is very good,
the whole process is nearly foolproof:

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

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

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.

Now it is time to merge the US's changes onto our own projects
(which have since continued developing):

cvs checkout -r avs-3_2 proj
cd proj
cvs update -d -j release-3_2-v1 -j release-3_2-v2
commit

That bit will actually work OK.

cvs rdiff -s will not produce useful results because it will see lots
of version numbers changing.  I've already got patches to CVS to
fix that.  cvs rdiff (no -s) works fine out of the box.

But when it comes time to merge onto the dbbe-3_2 branch, with:

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
wouldn't mind getting this error *IF* the file that the US sent us
is different from the one on the branch.  And if the file that the
US sent us is different, which it invariably is, then what I would
expect to see is "<<<<" markup in the file, and a conflict marked.
Instead, there's nothing, it doesn't failsafe, and if I don't catch
that brief error message, I will lose the file change from the
US.

As such, I have in my procedure, that whenever I do an import
and an update, I grep for "has been added", and then manually
do a -j dbbe-3_2 -j release-3_2 which is normally what I want.

There is no reason why this shouldn't be done automatically, and
the whole software development procedure be foolproof.  CVS
comes so damn close.  I was shocked when I found that CVS
now handled adding and deleted files automatically as part of
the update.  That's not how I remembered the behaviour back
at version 1.2-1.10.  I always used to have to process them
manually.

But now it's even more bloody brilliant and comes so close to
being complete.  But doesn't quite go the full distance.  :-)

I don't know any way of setting up CVS better than it already is,
but I'm open to suggestions.  Remember, USA sends the official
releases to Australia, and Australia has multiple, independent
projects based on the US's shipments.  There's not just one
project, there's 2-4.  And they don't necessarily start at the same
time, so they are always branched off the latest available US
shipment.

But once a group has their sandbox, they get to keep it.  I merge
in the new changes from USA, they just need to do a "cvs update"
when I send out an email.  No need for them to treat the US's
changes any different than they treat other members of their
project, who also make changes, and also require them to do
occasional updates in their respective sandboxes.

BTW, the US doesn't use CVS, so don't say "use a remote server".
The releases that are sent to me are sent by another department
and it is not under my control.

As far as I'm aware, the system is set up as well as it can be.
The limitation now is quirks in CVS.  But it's BLOODY close
to having full closure.  Which is why I'm very interested in
getting 1.11.x to be completely foolproof.  It's tantalizingly
close.  I guess most people don't see the problems because they
are working on the head, because they only have two branches,
one being the vendor, the other being themselves.  Development
on the head doesn't work when you have multiple projects in
a large development effort.

BFN.  Paul.