[Top][All Lists]

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

Re: import inconsistency

From: Paul Edwards
Subject: Re: import inconsistency
Date: Sat, 14 Jun 2003 04:00:04 GMT

"Pierre Asselin" <pa@invalid.invalid> wrote in message 
> Paul Edwards <kerravon@nosppaam.w3.to> wrote:
> > All the messages I have seen in here appear to be coming from
> > people who use the head.  I haven't seen any indication that
> > people are adding files on a branch and then importing over
> > them either.
> Having a trunk is normal.  Your branches that never get merged are
> very unusual.  Your imports into such trees are *exceedingly* unusual.
> Yet, the update bug that you found --and it is a bug-- has nothing to
> do with branches, dead files or Attics.  Remember what I posted earlier?

There are two (at least) separate issues, and you don't appear
to have separated them from my various comments.

The update bug has nothing to do with Attics.

>     import a test tree
>     check out the trunk
>     add a file "gatcha" on the trunk, commit, delete the sandbox
>     add a file "gatcha" to the initial import tree, do a second import
>     cvs checkout -j first_import -j second_import
> The "gatcha" conflict is flagged by a single, ephemeral error message.

The test case I submitted, along with a workaround, did
not even use any branch, since I expected, correctly, that
it would show up even on a trunk.

> > Apparently all this time I was the only one who ever did a
> > cvs diff between two tags too, and noticed the corresponding
> > bug on deleted files.  Presumably the many active repositories
> > don't use "cvs diff" much?  Or "cvs rdiff -s" either.  Or maybe
> > there aren't that many truly active repositories like mine?
> You probably had better odds than most of bumping into that one.


> In truth, your problem is that you're trying to do multisite development,

Alone?  Why always alone???!!!

> and CVS assumes a central server.

I don't see that.  That's specifically what imports are for.  It
is specifically set up for vendor branches.

> Your company would do a lot better
> if *you* ran the server.  The US guys woud just have to buy themselves
> some bandwidth!

Ah, well, they run a PVCS server and expect us to be the ones
with slow access, via a GUI no less!  I am not actually familiar
with PVCS though, but had confidence I could set CVS up to
do what I wanted.

My ultimate suggestion to them is that they get their PVCS guys
to implement project branches in the same way that I have set
it up in CVS.  At the end of the day, I know that I am running
CVS unsecurely (all developers can trash the repository) and
I want to divest myself of that responsibility.  But I have also
told them that we want fast access, so a local PVCS repository
mirror or something like that is required, or simply an
unmirrored one and we can do exports etc.

But there is a management problem making that difficult, as
developers and change management are two different groups,
and change management don't actually have any problem
themselves, it's only developers (with the multiple projects)
who have an issue with merging.  Production support doesn't
have a problem.

If that situation persists, and I can see the rough logic behind
it, then that is no problem, it can be branched and merged in
development and then there will be a single outcome going
into PVCS.  This is what I have implemented.  But it will
seriously backfire if:

1. Someone trashes my "unauthorized repository".

2. I am not around when there is a problem, and someone says
"Paul implemented this complex CVS system and is the only
one who can fix it and he's sick for 2 weeks, let's sack him for
implementing unauthorized processes using unauthorized
software in a transparent attempt to keep himself in a job".

Branches are a very complicated (and very beautiful) thing, and
it requires a lot of understanding.  It is difficult for me to
implement something that people don't understand.  It takes time
for them to see the end result (0 code merge problems from
Sydney, but maybe that was a fluke or maybe we don't do much
work down here) before they can even believe that there is some
benefit to all the overhead involved in implementing this.

But I implemented it anyway, because I knew I would certainly
make code merge errors otherwise, and I would get harassed
for that, and my true response to that is "Of course I made a
code merge error, it's not my fault, it's your stupid Change
Management system that is at fault".  I will be right, but they
won't understand that I'm right.  So I took the risk of implementing
CVS, the lesser danger, before anyone caught me making a merge
error, as I'm not very good at manual tasks, I've got the
attention span of a budgie.  :-)  I'd rather they didn't find out I'm
not very careful.  I'm better at producing processes that failsafe.

BFN.  Paul.

reply via email to

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