On Wed, Jun 14, 2000 at 03:56:06PM -0500, Robert Bresner wrote:
>
>
> Donald Sharp wrote:
> > Bad Mojo. Don't go there. Does PVCS treat branches
> > and files the same as cvs?
>
> Honestly don't know. PVCS, being a very expensive product,
> is unavailable to me, and the customer using it has a similar
> amount of CVS knowledge that I have of PVCS.
> Their mindset of version control is completely different from
> ours, in that ( in my terminology ) they have a mainline branch
> where all development is done, then they create a branch
> for a debug release, which is expired after a time.
> (Think of the tree analogy diagram, not of CVS vs. PVCS internals.
> When their tree branches versus when our tree branches. )
>
This is a valid way of working. They just answered the question
differently of what are branches for?
>
> > How do you intend to merge
> > conflicting changes made to the same file without creating
> > a administrative nightmare?
> Well, after a grand total of three minutes of thinking about it
> during The Meeting the other day, I've recognized that the nightmare
> cannot be avoided. This makes me very very sad, and makes me long for
> early retirement.
>
> > > Perhaps a better question is this one:
> > > Is there a CVS implementation anywhere
> > > that mimics PVCS security features?
> >
> > What are PVCS security features? Why wouldn't using cvs via ssh
> > be more secure?
> PVCS (apparently?) provides security on a file by file basis. Or, at least
> an 'object by object' basis (or, in my CVS world, a "directory by directory"
> or, "module by module" basis ) on a user by user basis. Where user A can check
> out a directory, but not check in changes. User B can not check out _that_ dir,
> but can check out some other dir. And User C can checkout and checkin those
> dirs.
> PVCS has locking (which is a world of trouble in and of itself) during a checkout,
> so if a user checks out a file, no one else can check that file out for editing.
> (I don't see this as a feature, I see it as a methodology flaw. We have developers
> humping through all directories all the time. Wee! PVCS would shut us down. Imagine
> forcing one developer to sit for three hours, or days, or weeks while some other
> developer is adding whole new features to existing code.)
>
> Relying on *nix security wouldn't work here because Solaris is the *nix and it has
> issues with the number of groups that a user can belong to. And, we'll be needed some
> 20-30 groups, times 2 for read access and write access.
> Relying on NT security (since most of the developers will be playing on NT)
> always gives me a good laugh, so I bring it up for you to also enjoy.
You can probably implement the security that they really want with
modules and control scripts that let people checkin/checkout modules...
>
> In my leetle mind, I imagine some Perl script running at night, which would
> (ugh) file by file pull down the latest PVCS and CVS versions, merge them,
> (this is starting to sound more and more like a mad scientist pipe dream to
> me as well) and return them to their respective repositories.
I still don't see how you can decide what is a good merge and what is a
bad merge in the case of a conflict.
For instance:
Suppose that developer a is working off a cvs repository. Developer
b is working off a PVCS repository. File 'foo' contains the function
bar(). One day developer a modifies bar() such that it now defribulates
the nominator and commits the code. The same day developer B modifies bar()
such that it now discombobulates the nominator and commits the code.
What *CHANGE* are your scripts going to make? How are you going to
track what the correct thing to do is? How are you going to sync up
the repositories? How are you going to prevent either a or b from
adding more mess to the bar() function the next day?
This is the type of administrative nightmare you are buying yourself.
And frankly that just doesn't suck, it's a job killer. If I were you
go back to your bosses and tell them that they need to choose one
standard System for the company to use for Source Code Control. The
minute you try to use two different systems and then make them both
interact to contain the same data you are asking for more than a world
of hurt.
donald
>
> Politics, you see, is driving this right now, and I, being the cog, need to
> find a way to make it work, or in very lay man's terms explain to the parties
> involved exactly why and how this cannot be done. So far I've failed, because
> I don't know enough about PVCS, and the PVCS guy doesn't know enough about CVS.
> The knowledge transfer we've had thus far tells me that PVCS is not right for
> this project at all, and the tells the PVCS guy that CVS is not right for the
> project. Tada! And the world continues it's journey around the sun, and the
> roaches in my apartment continue to enjoy a fruitful life.
>
> Anybody? Anybody? Beuler? Beuler?
