[Tfug] Version Control

[Bexley Hall]

Hi John,

>> As for the automatically figuring out what diff tool to use thing, git can
>> definitely use file extensions (as shown here:

>> One solution would be to
>> set up a default differ (as in here: http://jeetworks.org/node/90) that
>> would determine the filetypes involved using "file" or something and then
>> call the appropriate application. This'll achieve the behavior you want, but
>> now you're stuck maintaining your diffing script (which may or may not be a
>> headache).
>
> Subversion has always done a decent job of this for me.  I *think* it
> uses file magic to determine the types of files which is stores in its
> database as MIME types.  If SVN does not pick correctly I have found
> it very easy to change the MIME type associated for one or more files,
> such as changing images which were given an only semi-correct generic
> "application/octet-stream" to a more correct "image/jpeg".  Of course,
> either way they were binary files.

The VCS should only "need" to know this to give meaningful ways of
presenting diffs and merging changes.  The problem with early VCSs
was the use of "file type" to determine line endings, how to
embed keywords, etc.  So, getting a type wrong meant the object
could be mangled irreversibly (and, that you might never be able
to detect this until you tried to checkout the object at a much
later date -- after the "original" has been discarded).

"Typing" an object is inexpensive -- even if done manually.  And,
need only be done *once* for each object.  But, you need a way of
*remembering* that!  (This is why it persists in the *name* of
the object -- since that's essentially the only metadata of an
object that persists)

> As for a Subversion GUI, the only one I have any experience with is
> the Subversive add-on for the Eclipse IDE.  I found it surprisingly
> good and full featured.  I have yet to find any SVN feature that *I*
> needed that was missing.  Perhaps more telling is that I have even
> been able to resolve repository conflicts using the GUI which is
> something one usually needs to use the command line for.  Of course,
> the problem with this particular "GUI" is that it requires Eclipse to
> function and, clearly, what's the point of that if you aren't actually
> developing with Eclipse?
>
> I have *not* used it, but I can see from reading online that the
> (unfortunately) Windows-only SVN client "TortoiseSVN" is very popular
> and very well liked.

Yes, I saw a "TortoiseCVS" but some mention that it didn't support
all of CVS's features (disturbing given that cvs has been stable
tot he point of STAGNATION for many years  :> )

> There is also a cross-platform project called
> RabbitVCS with the goal of offering a full GUI for several VCS
> (including Subversion, git, and Mercurial) and they seem to be using
> TortoiseSVN as the guide for the GUI design.  Unfortunately, RabbitVCS
> has a ways to go and currently only supports the Nautilus file manager
> and Subversion.

That's the problem I alluded to with "third party" GUIs.  One has
to wonder where the tools to which it interfaces will be when it
finally (hopes to) support them?  (i.e., always playing catch-up)

> As far as I can tell there are no "official" Subversion GUI programs
> that are developed lockstep with the VCS tools.
>
>> At some point, you've mentioned ad-hoc text files littering the heirarchy.
>> Git's a bit better than CVS and SVN in this sense, as it at least keeps all
>> of its stuff in the project's root directory (mostly in .git/, but custom
>> configuration such as submodules, per-project diff configs, and so forth
>> spill out into other dotfiles in this directory). This, however, has the
>> notable downside of being unable to check out a subdirectory of a repository
>> (like you can in SVN), so you should be aware of that. The stuff *inside*
>> the .git directory is described in the git book
>> (http://git-scm.com/book/en/Git-Internals) if you want to interface with it.
>> I think the general consensus is that if you are doing that, you're doing
>> something wrong.
>
> This is something the Subversion developers have finally corrected
> with version 1.7+.  There is now a ".svn" directory in the root of the
> tree you checked out and nowhere else which is very nice.   As far as I
> have been able to tell, this change has *not* effected the ability to
> check out an arbitrary subdirectory in the SVN repository... but don't
> quote me on that.  :)

OK.  I'll watch for that.  Are you saying 1.7 is the version I should
evaluate?  Or, just that this change was *introduced* in 1.7?

> Just a few extra data points for your comparison, Don.

Thanks!  I'm trying to decide which machines to use to evaluate
everything.  The "easy" approach would be to set up 4 *identical*
machines (Solaris, Windows, *BSD) and install a server for each
VCS on each machine.  Then, alternately configure the 4th machine
as a {Solaris,Windows,*BSD} *client* to access each VCS.

(That's still a fair bit of work!  :< )

But, that ties up a lot of hardware.  I think I can, instead,
install {Windows,Solaris,*BSD} systems -- one at a time -- and
image the disk.  So, I can rapidly recreate a {Windows,Solaris,*BSD}
system on either of two identical machines (I think Windows being
the most "picky" regarding the hardware the image is reinstalled upon).
Then, install "VCS host OS" on one machine and "VCS client OS" on
the other, run the tests, then step to the next client/host.

A bit more work but means I only need to find *two* identical
machines (and *space* for two machines!!)

<frown>  I can see why folks don't do these sorts of evaluations...