Free Source Control system that doesn't require storing local copies of every file, thus doubling space usage?

Is there a source control system (besides CVS) that can be configured to NOT store local copies of files? Or 开发者_StackOverflow中文版perhaps it just doesn't do it by design? Ideally, one could configure such option by extension or file size.

For example, if I do sometimes want to store large movies or pictures in SVN, the end result is double the space usage on the client - and there's no way around it.

I realize one solution is just not to commit such files but my question is searching for that other solution.

For the record, I just tried Mercurial (Hg) and it used up twice the space as well. I suspect Git would do the same.

P.S. I don't see why SVN couldn't implement support for this already. How simple would it be - if a file is not stored locally, get it remotely, like CVS, I believe, does. If network is not available right now, show error. /vent

You can use Bazaar with a lightweight checkout of a branch. The working directory will only contain the editable source code and bzr will do a network lookup for almost any operation. But you will find that even if you use regular branches, the size of the branch with all the history is usually smaller than the working tree.

SVN (and all other modern VCS) was designed to store lots of small text files, not huge amounts of big binaries. The all keep a local copy because it's cheap (most projects will rarely use more than a few megabytes) and it makes almost all operations much faster (diff, status, local commit).

So you're using the wrong tool. If you need to manage images, try Picasa or something similar. Unfortunately, most image databases don't know how to keep the editing history of an image (which is a pity; I've opened a bug against digikam years ago and it's still open).

I mean, it would be much more efficient to keep the original image and just save the options for all the edits you made plus the current "final" image. Everything in between could be recreated from the original image and applying the operations again. No VCS in the world would be able to beat that in terms of efficiency ("Contrast +10%" vs. comparing two JPGs).

Therefore, your best bet today is either a professional photo editing tool (-> not free) or you must copy and rename photos that you want to edit.

Yeah, it sucks.

If all you know is a hammer, you'll treat every problem as a nail.

The only one which i have used which didnt incur any excessive extra usage space was the universally hated, visual sourcesafe.

SoureSafe 6.0 only incurs storage overhead for source bindings.

However, i consider SourceSafe as a source destruction system, so i dont recommend it at all.

ClearCase stores only locally modified files in your working area (called a view in their naming convention).

It might sound stupid (and perhaps it is), but once you have committed your big file, why you not just delete the file on disk? After all, the VCS can precisely be used to restore the file when you need it.

I just tried that with Bazaar:

> ls -al
total 7123
drwxrwxrwx   1 user     group           0 Oct  5 11:42 .
drwxrwxrwx   1 user     group           0 Oct  5 11:22 ..
-rw-rw-rw-   1 user     group     2469224 Aug 29  2007 Charles_Darwin_01.jpg
-rwxrwxrwx   1 user     group     4076719 Sep 25 15:35 FileZilla-3.2.7.1.exe
-rw-rw-rw-   1 user     group      746477 Aug 24 18:35 floorplan2008.png

> du -bs
7292420 .

> bzr init
Created a standalone tree (format: 2a)

REM Adding by name to override my own ignore rules, a simple `bzr add` is enough otherwise
> bzr add Charles_Darwin_01.jpg  FileZilla-3.2.7.1.exe  floorplan2008.png
adding Charles_Darwin_01.jpg
adding FileZilla-3.2.7.1.exe
adding floorplan2008.png

> bzr commit -m "Storing big binary files in repository"
Committing to: E:/temp/TestsVCS/Big/
added Charles_Darwin_01.jpg
added FileZilla-3.2.7.1.exe
added floorplan2008.png
Committed revision 1.

> du -bs
14552798        .

> rm Charles_Darwin_01.jpg  FileZilla-3.2.7.1.exe  floorplan2008.png

> du -bs
7260378 .

> bzr add Bazaar-quick-start-summary.pdf
adding Bazaar-quick-start-summary.pdf

> bzr commit -m "Adding good reference" Bazaar-quick-start-summary.pdf
Committing to: E:/temp/TestsVCS/Big/
added Bazaar-quick-start-summary.pdf
Committed revision 2.

> rm Bazaar-quick-start-summary.pdf

> du -bs
7666520 .

REM I want to work on a file
> bzr revert Charles_Darwin_01.jpg
 N  Charles_Darwin_01.jpg

REM I edited the file
> ls -l Charles_Darwin_01.jpg
-rw-rw-rw-   1 user     group     2419048 Oct  5 11:52 Charles_Darwin_01.jpg

> bzr st
removed:
  Bazaar-quick-start-summary.pdf
  FileZilla-3.2.7.1.exe
  floorplan2008.png
modified:
  Charles_Darwin_01.jpg

REM I commit by name to avoid to commit the deletions, 
REM but actually they can be commited without problem
> bzr commit -m "Changed just some IPTC tags" Charles_Darwin_01.jpg
Committing to: E:/temp/TestsVCS/Big/
modified Charles_Darwin_01.jpg
Committed revision 3.

> du -bs
12505785        .

> rm Charles_Darwin_01.jpg

> du -bs
10086737        .
REM + size of image + around 1KB of metadata

Note: that's on Windows but I use the UnxUtils commands, they are handy on the command line.

Just how big is your image library? These days, I think it would be cheaper to buy another 80GB hard drive -- if you can find one that small on the market -- than to buy a source-code control package with disk-space-saving features.