begin quoting Lan Barnes as of Wed, Apr 20, 2005 at 01:33:30PM -0700: [snip] > So what do we want from an SCM system? Here is a short and incomplete > list. > > - code recovery to any committed revision > - tagging/labeling allowing recovery of full code sets > - support of different lines of development > - support of maintenance (not always the same thing) > - prevention of code overwrites to both the repository and the work area > - rational merging mechanism for changes in code committed > - support for all development modules (binary as well as text) > - locking mechanisms to prevent overwrites of nonmerging modules
Locking is something that Very Large Organizations (or control-freaks)
really really want.
> - granular security to allow administrators to configure the repository
> for different levels of access
Beyond "you can make a change", "you cannot make a change", and "you
can't look at that", what additional levels are there?
Append-only? Modify-only? Add-only?
> - extensibility through scripting and triggers
> - visual tools to improve presentation of complex data
> - auditability to satisfy regulatory bodies internal and external
> - job/bug/issue/requirements tracking that associates changes with
> issues to the line of code and to the commit
Some of these make a repository just a piece in the SCM toolkit. The
visualization and requirement tracking especially seem well-suited to
be 3rd-party tools to bolt on to an arbitrary version-control system.
Otherwise I spent a lot of time nodding my head going 'yah, yah'. :)
[snip]
> Perforce is kind of a sports car. In the road grader category, I fancy
> Merant's (haven't they just gone through yet another acquisition/name
> change?) Dimensions. *Big*, expensive although not compared to ClearCase
> (the national debt is cheap compared to ClearCase), task driven, looked
> to us like a good product for those who want the Big Solution.
I've heard good things about Perforce.
Not willing to spend quite that much dosh, though, personally. For a
sizable company? Perhaps.
> But the real question posed here was CVS vs SVN. So let's see if I can
> encapsulate my reasons for preferring SVN so much.
>
> CVS:
>
> Upside:
>
> - everybody is using it and is familiar with it (_really_ weak argument
> to me)
> - umm ... umm ...
>
> OK, no more upside
- Can manage access with standard UNIX tools and paradigms
- Data stored as files in the filesystem, to be managed with standard
UNIX tools
- Compiles cleanly with minimum dependencies
- Installs simply and easily
- Generally "just works".
- Gets to call itself 'mature' as it's been around forever
> Downside:
>
- PSERVER. You forgot the biggest wart/hack/kludge/abomination!
> - not truly C/S with lots of consequences. All state is client side, and
> if that gets confused, you're screwed
If the state gets confused, it's trivially fixed, because all state is
on the client side. You don't need repository access to fix state
confusion.
> - security is a sick joke. Have you _looked_ at how they do it?!
Standard UNIX paradigms. Where's the problem?
> - terrible handling of binary modules
Granted. It handles 'em, however. Just not efficiently.
> - lack of atomic commits -- lose your connection halfway through a
> commit, and both you and the repository need to go to tape
Never had a problem with this. Then again, I don't do, nor do I like,
nor approve of, huge commits. Commits should be frequent and small.
> - poor support of file renames (you lose history)
No history is lost. The connection between the old and the new requires
user discipline, granted, but are we presuming malicious users?*
> - no support of directory restructuring
Granted. Generally indicates a poor design and you should start over,
however. This does not mean that you _can't_ restructure the directories;
it's just that the tool doesn't provide any explicit support.
> - kludgey and slow triggers. You end up doing hopelessly slow recursive
> loops over directory structures
Granted. Triggers have never been very appealing to me. I'd need to see
a system where they were used well, because all the talk about 'em fails
to be at all persuasive. ("wouldn't you like an email every time there
was a commit?" "HELL NO.")
So I'd have to be first sold on triggers, I suppose.
> - expensive operations, especially branching and tagging. The bigger the
> repository, the longer it takes
How big of a repository are we talking for this to be an issue?
Gigabytes? If the whole repository can be backed up to _a_ CD, this
is *not* a concern. A few tens of seconds is NOT a problem.
> - no real privilege granularity (maybe through triggers, but do you
> want to be spending your time making CVS work, or coding?)
Got a specific example? This sounds like pie-in-the-sky stuff.
(I ask for information.)
> Sooo ... most projects in CVS are r/o with contributors emailing patches
> and some poor snook of an admin merging them, tagging, branching, and
> generally catching hell because s/he's too slow etc.
That's because you don't want just anyone updating your repository.
> Now, Subversion:
>
> Upside:
>
> - mostly a drop-in replacement for CVS (i.e., most users won't have to
> relearn much)
The one redeeming feature.
> - everything I mention above has been fixed
Even if it wasn't broken.
> - the "everything is a copy/snapshot" paradigm is simple and flexible
Calling it a paradigm doesn't make it clear. Can you expand?
> - revisions are by commit, not individual to each file
Since I commit each file one at a time, how is this any better? Seems
to me it panders to those who like to make huge changes to the codebase
all at once, which makes my life (as a developer) hell.
> - because of URL design for defining repositories, webDAV enabled from
> the get-go
Total non-feature (for me).
> - data base design (Berkeley DB) allows hot back-ups, inexpensive
> (fast!) operations
So no using the standard UNIX tools and paradigms.
> - I personally find the mailing list and community for Subversion a lot
> more pleasant and less cliquey that the CVS community, which tended to
> be disparaging and nasty
I've found just the opposite, actually.
But that's probably because I'm unwilling to chase that dependency
chain, or to ditch all of my non-x86 systems and install RH-FC3+ on
the rest.... I get a bit tetchy when given such advice, and then told
it's "good design" that imposes such constraints.
[snip]
> Now I'm sure I've missed something on both sides of both, and when the
> Subversion web site comes back up (not responding right now, but usually
> at http://subversion.tigris.org), you can check it out for whatever else
> they emphasize.
I started a list of reactions to SVN features. I'll have to finish it
and post it...
[snip]
> I will add that I find the dependency stuff very annoying. I dealt with
> it in my usual fashion -- by waiting until Red Hat distributed it (FC3
> and later). Even with that, I haven't been able to make any of SVN's
> GUIs load, so they're untested so far, too.
The dependencies issue has been a show-stopper for getting SVN a fair
evaluation. Especially since I'm trying to make everything work across
a number of platforms and operating systems. Having to chase down that
dependency chain ain't my idea of a productive use of my time.
> I would strongly suggest that CVS has outlived its usefulness. Know how
> to use it, sure; to allow yourself access to all the old CVS archives.
> But if you're setting up a new project, do yourself a favor and learn
> Subversion. It lives up to its mantra of being "a compelling replacement
> for CVS."
I figure SVN will be ready to replace CVS in about five years, once
they've matured a little and trimmed away most of the dependencies,
or at least made 'em honest-to-goodness optional.
In that time, CVS may have fixed many of the warts that so bother
people. Who knows?
-Stewart "CVS has warts, but she smiles. SVN cracks the whip." Stremler
* What happens+ when you have version-control tool 'foo' with a 'rename'
capability, and two files, A and B, and you go:
$ foo rename B C
$ foo rename A B
$ foo rename C A
$ foo rename B C
$ foo rename A B
$ foo rename C A
And then try to look at the history of A and B...
+ Or "should happen", as the case may be.
pgpoa1q3Y9ABN.pgp
Description: PGP signature
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
