[Tfug] Question the second: Revision control

[John Gruenenfelder]

On Thu, Aug 14, 2014 at 03:48:42PM -0700, Nick Lopez wrote:
>> 
>Git pretty much does everything SVN ever did better and faster, though maybe
>at the cost of disk space. Once you get used to the DVCS paradigm it’s very
>freeing. I feel that an old school centralized VCS causes code not to be
>committed until it’s complete and “perfect”. With every checkout being a
>fully functional repository you can commit any ‘ol incomplete, hair brained,
>change and have that history to revert to or diff against while you’re
>refactoring or spawn branches to try different things, then when it’s
>“perfect” you push that version up to the share repository, or as ask whoever
>you’re collaborating with to pull the changes from your working repo.
>
>I have one repo where I keep a few branches for minor mostly cosmetic tweaks
>between instances; with SVN that might result in big messy merges whenever I
>had to update one of the special branches, but with Git it’s just a quick
>“rebase” and it shoves the changes in the branch off to the side and syncs up
>with master branch, then reapplies the branch’s changes. There’s no conflicts
>with my changes in the branch conflicting with anything that was going on in
>the master branch because the changes don’t get reapplied until all the other
>changes from master get merged. All the branches and their histories then get
>pushed up to a central GitLab repo for backups and shared access.

Nick,

I've been meaning to thank you for your explanation.  Based on your glowing
endorsement, I decided to give git a try.

And... it's extremely nice.  After a short tutorial on basic commands, I found
it quite easy to use.  I switched a few (very) small projects from Subversion
over to Git to experiment and it worked quite well.

You're right that it is significantly faster than Subversion for pretty much
all operations, though it does use substantially more disk space.

Over the past few years I've seen a number of posts on the web as well as
distribution packages for systems allowing one to store $HOME in a version
control system repository, usually git.  So, I thought I would give that a
whirl, too.

Doing so required a fair bit more work and uncovered more than a few git
related issues of which I was unaware (but now I am).  A lot of the issues
were solved when I discovered the difference between regular and bare
repositories/checkouts.  And then I learned that the method by which git
stores data is very different from how SVN/CVS stores data.  In particular,
git doesn't specifically store UNIX permissions.  It only stores some
information, like whether a file name is an executable or if it is a link what
that link points to.

This presents a problem with some files in $HOME where group/other permissions
are very important to some programs.  I found a few solutions to this issue,
eventually settling on a program called "metastore".  Given a list of files
and directories, metastore will scan them and record their metadata.  You can
then use metastore to apply that stored metadata to those same file and
directory names.

The whole point of storing my $HOME in a repository was to make it easier to
keep those files in sync on several hosts.  By storing the metastore metadata
file in the repository, I can easily transport it and apply it when
necessary.  And by keeping a (rather substantial) .gitignore file in the
repository I can use git to store and transport only those files that I want
to share between hosts (mostly files that are not specific to any particular
host).

So, all in all, I'm quite happy with git.  I have the bare repositories stored
on my file server.  Doing this allows me to checkout copies on multiple hosts
without constantly running into conflicts.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20141002/d6f44d24/attachment.bin>