A proposed Subversion vision and roadmap [LWN.net]

A proposed Subversion vision and roadmap

Posted Apr 4, 2010 9:50 UTC (Sun) by epa (subscriber, #39769)
In reply to: A proposed Subversion vision and roadmap by dskoll
Parent article: A proposed Subversion vision and roadmap

Agreed. There are just too many stages in 'saving a file' for nontechnical users to easily grasp Git.

When we first start using a computer we soon learn that what we see on screen is not permanent
until we 'save' it. Simple version control adds another step, 'commit'.
With a DVCS you must also 'push' to get your changes upstream.
Git adds yet another staging point: the index, where files go
in between save an commit.

Surely all this could be simplified a little?

(Log in to post comments)

A proposed Subversion vision and roadmap

Posted Apr 5, 2010 12:25 UTC (Mon) by efexis (guest, #26355) [Link]

Inotify! With Linux::Inotify2 for Perl and shell based stuff like inotifyd (and other language equivs), scripting those kinds of things to happen automatically on a Linux system becomes pretty easy; you can just have the commit stages (I presume, I've not used git myself yet) on file update detection. I often use it for clients who run Windows, connecting to Linux system running Samba. They drag a file into a specific shared directory, upon the fclose event my code kicks in, processes it, spits them back out the processed result. I don't have to write any kind of interface, they don't have to learn one, I love it, has the potential to be my hammer-for-everything though so don't be surprised if it's not helpful here!

A proposed Subversion vision and roadmap

Posted Apr 7, 2010 20:43 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

One git frontend which tried to hide the index was cogito, currently deprecated. At first, it was confusing to have to consider the index at all. Nowadays I mostly forget about it, but when I need it it is extremely handy.