On Sep 22, 2015, at 7:06 PM, Paul wrote:
> 
> Andrey Repin writes:
>> Git, Subversion... basically any sane VCS out there.
> 
> I've managed to avoid version control all these years
> because I wanted the convenience of bash file management and changing
> things on a whim as I see fit.

The only file management task that VCSes force you to do through the VCS is 
file moves/renames and deletions, and that’s only because a VCS can’t work out 
how to manage the files you told it to manage if there isn’t a file where you 
told it to expect one.  All changes to the file *content* can — and normally 
*are* — done outside the VCS.

Normally you check your changes into the VCS shortly after you make them and 
are happy with the changes, but it’s quite possible to put off check-ins for 
weeks or months.  I don’t do that at work on source code repositories, but I 
have one repo at home that backs up changes to things like ~/bin which 
sometimes lags way behind “current” like that.

That’s where the VCS’s diff command comes in handy.  It answers the question, 
“What did I change in this file 4 weeks ago?”

If you were using zip as the archiving format because you want a single file 
you can move between systems, I recommend that you look at Fossil, rather than 
the more popular VCSes:

   http://fossil-scm.org/

Fossil’s repository is a single well-strucured, compressed file, which makes it 
easy to back up, move to other machines, etc.  (It’s a SQLite database file, if 
that means anything to you.)

If you actually need ZIP files (or tarballs) for some reason, there is a Fossil 
command to get a particular point in history as an archive.

One of those points in history is called “tip”, meaning the state of the whole 
repository as of the most recent checkin, which means it’s a single command to 
get a zip file of all files at the tip of the Fossil repository.

Subversion is a bit simpler to use than Fossil, but its default storage format 
is a big pile o’ files, which means you pretty much need to do repository 
management through the svnadmin tool.

Git is even worse than svn in that the pile o’ files is in the same tree as the 
working file set, instead of a separate tree.

Git is also more complicated than Fossil:

   http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

> And for lack of time to learn yet another system.

You should be able to get started with any sane VCS in maybe half an hour.  
Learning all the ins-and-outs will take time, but there’s power in mastering 
the details.

In terms of complexity, Subversion < Fossil < Git.

The only reason for someone with simple needs to go with Git is that you need 
the interoperability it provides, since it’s becoming the lingua franca of the 
developer world.  There’s something to be said for going with the standard, 
even if it’s a PITA in some ways.  

But I’m not telling a Windows user something they don’t already know with that, 
am I? :)
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Reply via email to