workflow idiom to compare zip/tgz with folder subtree

[Warren Young]

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