Version control system better suted than SVN

[Chanoch (Ken) Bloom]

On Sat, 2009-04-18 at 19:48 +0100, hessiess at hessiess.com wrote:
> I have recently started storing all of my data (not config files) in a
> subversion repository. Previously I was using unison to synchronise my two
> computers, but annoyingly it won't work over the collages proxy server due
> to SSH being blocked. SVN however does work because it can be used over
> HTTPS, with the added advantage of version control, reducing the chance of
> loosing data and also the need to store files which `may be useful
> sometime'.
> 
> One problem I have had with SVN is it storing 2 copies of everything in
> the working copy, which in the case of my home directory is much more
> space than I actually have available on my laptop. So are there any
> version control systems which, like SVN store all revision history server
> side and work over HTTPS, but unlike SVN, only keep one copy of each file
> in a working copy.

I think bzr may solve your disk space problem, though it reintroduces
the protocol problem, since its http and https options are read only.
(ftp operation might work for you though.)

A full summary of your options:

      * CVS only checks out one copy of the files involved. These
        revision control systems have severe drawbacks for everyday use,
        though you might look at Joey Hess' article "At home in
        $CVS" (http://kitenet.net/~joey/cvshome/) to see that it can be
        done. All operations (including diff) have to go out to the
        network. The CVS directory in your working copy, though ugly, is
        very lightweight. (See
        http://www.linuxdevcenter.com/pub/a/linux/2002/01/03/cvs_intro.html)
      * Subversion keeps two copies as you have mentioned.
      * SVK keeps one copy in your working directory, but it also keeps
        a local repository somewhere which probably has the same
        drawbacks as your subversion issue (though the local repository
        could in principle be located on a different partition if that
        helps your problem.)
      * Git keeps a local repository with full history in your working
        directory. This means at least two copies of everything are
        stored. [The amount of history can be controlled by using the
        --depth option when you pull, but this can cause pushing and
        merges to fail. The git manpage warns of this, but in practice
        the warnings are a bit strict compared to the actual behavior,
        and you can always fetch the history further back if you have a
        problem, and then things should work. If you use the --depth
        option, the amount of history will stored locally will grow over
        time anyway. There is no provision for forgetting old history to
        save space, short of blowing away your local repository and
        cloning anew. The --depth option can't get you any smaller than
        two copies of everything.]
      * Monotone and Mercurial seem to work like git. They may not
        support limiting the amount of history you grab on an initial
        pull.
      * Darcs supports --lazy checkouts, which "get patch files only as
        needed". (They advertise this right on their home page, when
        tell you how to get their source code from their own darcs
        repository.) I think it might keep patches around as it decides
        it needs them, meaning that your locally stored history may grow
        backwards in time as well as forwards, as you do more stuff with
        your working directory.
      * Bzr supports history-less checkouts. See
        http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#getting-a-lightweight-checkout They also discuss other strategies for saving disk space when cloning repositories.

-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20090419/8daeccac/attachment.pgp>