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