This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: workflow idiom to compare zip/tgz with folder subtree


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]