[Tfug] Version Control

[Bexley Hall]

Hi John,

On 3/25/2013 10:15 PM, John Gruenenfelder wrote:

> I have been using Subversion for quite some time now, ever since I
> ditched CVS.  SVN is, by and large, very similar to CVS, of course,
> but there are a number of architectural changes/decisions that were
> made early on to remove some deficiencies of CVS.  For example, with
> Subversion you can now rename and move files without needing to
> remove/re-add them to the repository (which will destroy existing
> history/versions as a side-effect).

Can you change the structure of the "managed hierarchy" between
versions?  E.g., can I change:
    sounds/{phone.wav,phone.au,doorbell.wav,doorbell.au}
to:
    noises/sun/{phone,doorbell}    -- were .au files
    noises/windows/{phone, doorbell}    -- were .wav files
So, when I check out the "after" version, there is no "sounds"
directory in my workspace?  Yet, if I opt to check out the
*earlier* version, there is no "noises" directory?

> There seems to be some debate online as to how true a *replacement*
> SVN is for CVS instead of just an alternative, but from my usage I
> haven't found any reasons to go back.
>
> Subversion nicely gets around the file variety issues by treating
> everything as binary unless it knows that it is a text file.  Much of

But, how does it decide that it is a text file?  By *hoping*
the file name indicates itself as such?  (i.e., *.c, *.txt, etc.)
Would it know that one "phone" file is in Sun audio format while
the other "phone" is a WAV file?  And, that "documents/phone"
is a text file describing how the phone *works*?

> the time it will also correctly detect the file MIME types, which I
> suppose is more useful if you are using a web front-end of some type.
> Also, Subversion defaults to *not* enabling keyword expansion, unlike
> CVS.  This is important since it greatly reduces the chances of your
> tool corrupting your files.  CVS defaulted to having this on, so if
> you were unlucky enough to have a binary file with "$Id$" in it...

Or even a *source code* (or text) file that is unfortunate
enough to have this "affliction".  (keyword expansion needs
finer grained control, IMO).

E.g., I never use two contiguous question marks in a source file
(like: printf("Why did you do that??\n");)

I got bit by CVS on a large project early on as it went through
"mangling" source files that it had no "right" to alter.  And,
its not an invertible process!  You have to find the original
files to recover from such an import...

> oops.  I use this feature so I made a shell alias to easily enable
> keyword expansion on specified files.  Since it can handle binary
> files, Subversion is also much better at storing these diffs.
>
> As far as I know, Subversion should meet all of your other
> requirements, too, such as space efficiency, available GUIs, ability

Is the GUI a "bolt on", after-the-fact, separate/independent
project?  Or, is it part of the VCS itself?

> to run the server on a variety of hosts, and so forth.  Glen mentioned
> in his reply that SVN does not meet your performance requirements...
> I'm not sure I can really comment about that.  I've never had any
> issues, but I can pretty confident that none of my repositories are of
> a size that anybody would consider large.  Maybe it becomes much
> slower with a large repository?
>
> I should mention, though, that I've still not got around to learning
> what I should about Git usage and features, despite how common it has
> become.  That's a big reason I stick with Subversion, actually, but it
> works for me.

That's usually the case -- for things *you* own!  OTOH, if
you import other projects, you often get stuck dealing with
a variety of different VCS's and ad hoc build systems.  If
you want to *track* the (ongoing) progress of those projects,
then you usually don't have much choice but to maintain their
existing "mechanisms/policies".  OTOH, if you *don't* intend
to track them (or, if the project is dormant), its usually
best to bite bullet at the start and "fix" things so they
work with your own mechanisms/policies.  In the process, you
often get a better feel for "what's where" (why do folks
omit such a valuable roadmap??) and how things *appear* to
work!