[Tfug] Version Control

[Bexley Hall]

Hi Glen,

>> I'm reconsidering whether or not to continue with CVS
>> or switch to some other CM/VC toolkit.
>
> Your requirements as I read them are:
> - Support any file type without any specific system configuration
>    required.

It shouldn't be *required* -- though, obviously, *opting* to
provide information regarding the type(s) of the objects
should allow the VCS to exploit that knowledge.

E.g., cdiff's make no sense for compiled "binary" executables
but are invaluable for "text" files.

(Ideally, a VCS would allow a "diff-er" to be specified for
each file type to present diff's in an manner "useful" for
that type of file.  File type should not be inferred from
a file's name!)

> - Commit from any level of the file hierarchy without knowledge
>    of what is in it.

This is essentially a consequence of the previous constraint.
If the VCS treats certain types of files (which it possibly
*incorrectly* infers!) differently, then a prudent user needs
to have intimate knowledge of the VCS's rules to ensure the
integrity of the objects managed therein.

(This is usually a liability of VCS's that like to add their own
metadata *to* the managed objects -- instead of storing that
in a true "database")

> - Must have centralized storage capability.
> - Size of repo should not be limited except by disk space.
> - Performance should not be affected by size of repo.
> - GUI's available

A GUI that doesn't track the feature-set of the VCS tool
AS IT EVOLVES is useless!  I.e., the folks responsible for
maintaining the VCS should also handle the corresponding
GUI.  I'm tired of having to "do something in a console"
because a GUI *claiming* to work with that tool hasn't
caught up with the changes/improvements in that tool!

E.g., CVS is no longer actively maintained.  Yet, there
are GUI tools that *still* don't allow you to do everything
that you can from the command line!

You skipped over:
- repository (ideally) hosted on a *BSD host
- "clients" available for Solaris/Windows/*BSD
- support for very large objects (~100MB)

> I assume you have excluded some of the more common revision
> control systems for a reason. For example, Git, Mercurial,
> Subversion, etc. Can you fill us in on why?

I've ruled out *nothing*!  I've been canvassing friends and
colleagues (not just "programmers" but folks who write
documentation, design hardware, etc. -- since all of those
activities should be handled by a single VCS!) to see what
they've used, whether it was their decision (or one imposed
upon them), the pros and cons as well as their "if I could
pick something, I would pick..." (and *why*)

> With the full realization that there might be valid reasons you
> have not mentioned them, I recommend either Mercurial or Git. Yes
> they are distributed revision control systems, but that does not
> prevent you from configuring it with a centralized "master"
> repository. I believe they both meet all your requirements.
>
> This may not affect my recommendation, but your requirement
> regarding performance is vague. Now, I know you like to write for
> a living, but if you can be more specific with fewer words than
> your average post, that would help me out. Here are some possible
> actions that could be affected by repository size:
>
> - View log
> - View status
> - Update
> - Commit
> - Branch
> - Merge

All operations should take place in time proportional to the
*conceptual* work they are performing.  E.g., checking out a
file of size X should take effort proportional to X -- regardless
of the number of revisions it has undergone.

OTOH, viewing the *log* for X should take effort proportional
to the number of entries *in* that log!  OTOOH, viewing the
most recent log message (or current status) should take (near)
constant time regardless of number of log entries, size of object,
etc.

> Subversion, the natural successor to CVS, does not meet your
> performance requirement unless branching is the only thing you
> care about from the list I provided.

Was that clarification short enough for you??  :>