×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Performance Tuning Subversion

ScuttleMonkey posted more than 6 years ago | from the geek-tweaks dept.

Programming 200

BlueVoodoo writes "Subversion is one of the few version control systems that can store binary files using a delta algorithm. In this article, senior developer David Bell explains why Subversion's performance suffers when handling binaries and suggests several ways to work around the problem."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

200 comments

Why binaries? (2, Interesting)

janrinok (846318) | more than 6 years ago | (#19243411)

I know it can handle binaries, but I cannot think why I would want to. Can anyone help?

Re:Why binaries? (0, Redundant)

janrinok (846318) | more than 6 years ago | (#19243443)

And yes, I have RTFA. I just cannot think why I would want to do what they suggest...

Re:Why binaries? (4, Insightful)

rblancarte (213492) | more than 6 years ago | (#19245369)

I was thinking the same - especially since I use Subversion.

But taking a quick look at the article, I get an idea - storing your binaries at different version levels w/ it. Say I am developing a software package, us SVN for each level of revisions. With major releases I could store the produced binaries with the package to prevent the need to recompile when I am pulling down a version. Basically it would truly version control your binaries as well.

In some ways the article makes me wish I did that with the project I am currently working on. I might start doing it now.

-R

Re:Why binaries? (3, Informative)

autocracy (192714) | more than 6 years ago | (#19243491)

First answer: Images. Many other possible answers... :)

Re:Why binaries? (5, Interesting)

daeg (828071) | more than 6 years ago | (#19244585)

Not just images in the sense of PNGs and JPGs, but original source documents as well (PSD, AI, SVG, etc). We track several large (40MB+) source files and I've seen some slowness but nothing to write home about.

We give our outside designers access to their own SVN repository. When we contract out a design (for a brochure, for instance), I give them the SVN checkout path for the project, along with a user name and password. They don't get paid until they commit the final version along with a matching PDF proof.

This solves several issues:

(a) The tendency for design studios to withhold original artwork. Most of them do this to ensure you have to keep coming back to them like lost puppies needing the next bowl of food. It also eliminates the "I e-mailed it to you already!" argument, removes insecure FTP transfers, and can automatically notify interested parties upon checkin. No checkin? No pay. Period.

(b) Printers have to check out the file themselves using svn. They have no excuse to print a wrong file, and you can have a complete log to cross-check their work. They said it's printing? Look at the checkout/export log and see if they actually downloaded the artwork and how long ago.

(c) The lack of accountability via e-mail and phone. We use Trac in the same setup, so all artwork change requests MUST go through Trac. No detailed ticket? No change.

(d) Keeps all files under one system that is easy to back up.

You may have a little difficulty finding someone at both the design and print companies that can do this, but a 1 page Word document seems to do the trick just fine.

Re:Why binaries? (0)

Anonymous Coward | more than 6 years ago | (#19243511)

To keep DLL/SO files you're linking to locally? I don't know, just guessing.

Re:Why binaries? (-1, Offtopic)

CogDissident (951207) | more than 6 years ago | (#19243529)

This appears to just be an advertisement for the software called Subversion. Its not common software, and it certainly not in use outside of the core, high level network techs. Its certainly not news.

Re:Why binaries? (4, Insightful)

autocracy (192714) | more than 6 years ago | (#19243643)

Oh, I shouldn't feed trolling... but he does have an account... The target audience and main users of Subversion are not "high level network techs." Software developers / coders is where you want to look. That said, I'm disappointed in the article... I was hoping for tweaks rather than "use a tarball." The information / stats provided was interesting, though.

Re:Why binaries? (1)

janrinok (846318) | more than 6 years ago | (#19243729)

I wasn't trying to troll. I had a genuine question. It has now been answered.

Re:Why binaries? (0)

Anonymous Coward | more than 6 years ago | (#19243821)

Click the "parent" link, he was replying to a post by CogDissident (951207), not to you.

Re:Why binaries? (5, Informative)

Anonymous Coward | more than 6 years ago | (#19243557)

putting a toolchain under CM control, so that you can go back to not only an earlier version of your own code, but the version of the toolchain you used to compile the code at that point in time. Absolutely necessary to be able to recreate the full software environment of a past build, without relying on that version of the toolchain still being publicly available (not to mention including any patches/mods you made to the public toolchain).

Re:Why binaries? (1)

janrinok (846318) | more than 6 years ago | (#19243613)

Thank you. This is an answer that I can relate to. Still not what I need, but I can see why some people might want to do it.

Re:Why binaries? (1, Informative)

Anonymous Coward | more than 6 years ago | (#19244317)

For this you should create a software repository that you store your jars / exes / binary files and include their version number in the name or directory. Then back it up.

Version Control is for when you can actually see a difference in versions.

If you have jars checked into CVS / SVN you should move to using something like Maven so you can store your internal jars on a web server.

running the toolchain... (3, Insightful)

iangoldby (552781) | more than 6 years ago | (#19245071)

If you put the toolchain into CM, do you also put the operating system in? Just as the sourcecode is no good if you don't have the right toolchain to build it, the toolchain is no good if you don't have the right OS to run it.

I suspect the answer (if you really need it) is to save a 'Virtual PC' image of the machine that does the build each time you make an important baseline (or each time the build machine configuration changes). Since the image is likely to be in the GB size range, you might want to store it on a DVD rather than in your CM system.

Re:running the toolchain... (1)

19thNervousBreakdown (768619) | more than 6 years ago | (#19245375)

Don't forget, the VM is useless without the hypervisor/player/whatever, so you need to check that in too. Of course, that's generally useless without the OS, so check that in too. Even if you have an OS/hypervisor, that's useless without the hardware, so you need to check that in too.

Or, rather than trying to figure out how to version control hardware, you could write portable code and use open standards, and not worry about all mess.

Re:Why binaries? (0)

Anonymous Coward | more than 6 years ago | (#19243593)

Art assets for games. We do this at work (the games aren't too big).

For some reason they use Visual Sourcesafe at work, eurgh.

I tried to persuade them to use Perforce, but the boss was having none of it.

Re:Why binaries? (0)

Anonymous Coward | more than 6 years ago | (#19243795)

For some reason they use Visual Sourcesafe at work, eurgh.

I pity the fool that chooses VSS. Not even Microsoft themselves use that horrible excuse for a version control system. It's as if someone wrote it over the weekend and showed it their boss and he said "lets release it!"

Re:Why binaries? (5, Insightful)

jfengel (409917) | more than 6 years ago | (#19243615)

It's really nice to be able to have your entire product in one place and under version control. Third party DLLs (or .so's or jars), images, your documentation... just about anything that's part of your product.

That way it's all in one place and easily backed up. If you get a new version of the DLL/jar/so you can just drop it into a new branch for testing. If your customer won't upgrade from version 2.2 to version 3.0, you can recreate the entire product to help fix bugs in the old version rather than just saying, "We've lost it, you've got to upgrade."

Basically, by putting your entire project under version control, you know that it's all in one place, no matter what version it is you want. Even if the files don't change, you know how to reconstruct a development installation without having to dig around in multiple locations (source in version control, DLLs in one directory on the server, etc.)

Yeah, so it costs some extra disk to store it. Disk is cheap.

Re:Why binaries? (1)

Aaron Denney (123626) | more than 6 years ago | (#19243969)

Yeah, so it costs some extra disk to store it. Disk is cheap.

Disk is cheap, but bandwidth (and latency!) is not. Being able to send deltas over the wire is very nice.

Re:Why binaries? (2, Interesting)

jfengel (409917) | more than 6 years ago | (#19244255)

That's certainly true. It's tolerable when I'm on the LAN with the server. When I'm working via VPN from home, I get up and watch some TV when doing a full checkout of my system. (Some of that is the binaries, though much is just the sheer number of files and the latencies caused by the SSH.)

Re:Why binaries? (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#19243665)

images and jar files. 'nuff said.

Re:Why binaries? (4, Insightful)

javaxman (705658) | more than 6 years ago | (#19243743)

1) you want deployment without the need to build
2) you have proprietary build tools limited to developer use, or release engineers unable to build for whatever reason ( similar to #1, I know... )
3) images, of course.
4) Word, Excel, other proprietary document formats are all binary.
5) third-party binary installation packages, patches, dynamic libs, tools, etc.

You're just not trying, or you're thinking of version control as something that only programmers would use, and that they'd only use it to store their text source. There are as many reasons to store binary files in version control as there are reasons to have binary files...

Re:Why binaries? (1)

janrinok (846318) | more than 6 years ago | (#19244109)

I was trying, but as a hobby programmer I used it exactly as you described. I use it to store my scripts, source code and documentation.

Re:Why binaries? (1)

javaxman (705658) | more than 6 years ago | (#19244657)

I was trying, but as a hobby programmer I used it exactly as you described. I use it to store my scripts, source code and documentation.

Exactly... all you need for hobby projects. You don't have to worry about someone else needing your binaries. You don't have lots of images or proprietary-format documents ( some of which can get really large... think of a database as a document... ), and you don't even have to worry about someone being able to build your project w/o this dynamic library or that compiler or this other tool.

We have to worry about all of that stuff, and want every aspect of it to be in version control so we have a record of who changed what, and when... I'm sure you get it now. Think enterprise. Recent press releases from CollabNet typically include lines like "More than 300 industry leading companies use CollabNet's solutions today, including Reuters, Philips Medical System, Federal Express, Cap Gemini and Barclays Global Investors among others."... you can bet some of those folks have a binary file or two which need to be tracked in version control.

Re:Why binaries? (1)

norton_I (64015) | more than 6 years ago | (#19244271)

I use subversion to track latex documents, which have figures in them. I usually store both the original source file (often a binary) as well as the .eps version of figures (text, but might as well be binary) in svn, since I can't regenerate them from a script.

I don't understand why the author of the article wants to do what he is, but lots of people have good (or good enough) reasons for wanting to track binary files.

I always hope I don't have to keep binaries in svn, but since so many people seem to love them (for reasons passing understanding) I often end up with binary files under VC. Not sure why I would want it to track deltas... most binary files I can think of would not be likley to generate large common regions between versions, but I am sure it could be useful for someone.

Re:Why binaries? (2, Interesting)

IWannaBeAnAC (653701) | more than 6 years ago | (#19244641)

What you want is a makefile that will track the dependencies in the latex documents, and generate .eps files from the figures. There are a few around on the web, but I haven't yet seen a 'does everything' version. What program do you use to generate the .eps ?

Re:Why binaries? (1)

norton_I (64015) | more than 6 years ago | (#19246431)

Unfortunately, for drawings I usually use Illustrator or Canvas on Windows. I also generate figures in Matlab, which can be automated, but is a major pain to do so. Ideally, I would switch to Inkscape for the drwaing, but last time I looked at it (quite some time ago) it was not ready. I hear it is much better now, but I am not going to learn a new program halfway through writing my thesis.

Thanks

But why deltas? (1)

Weston O'Reilly (1008937) | more than 6 years ago | (#19244395)

The reasons given here are valid and pretty obvious reasons why you'd want to store binaries in version control. But what is the big advantage of storing deltas of binaries, instead of complete files like CVS? Is it just disk space savings?

Re:Why binaries? (3, Interesting)

jbreckman (917963) | more than 6 years ago | (#19244871)

We use it for version control and sharing of powerpoint/audio files. It keeps things considerably saner than a shared drive.

And yes, for a 250mb audio file, it is VERY slow.

watermeleons (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#19243449)

cornbread

Utter garbage (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19243475)

Visual SourceSafe destroys all open sores garbage. Subversion is for amateurs.

Re:Utter garbage (0)

Anonymous Coward | more than 6 years ago | (#19245499)

Visual SourceSafe destroys all open sores garbage.
Visual SourceSafe destroys anything you put in it :)

SVN will not replace CVS (IMO) (1, Interesting)

Anonymous Coward | more than 6 years ago | (#19243547)

Subversion fails to follow symbolic links that point to code that other projects share for the sake of a minority that still develops using Windows (which doesn't have real symbolic links).

CVS http://en.wikipedia.org/wiki/Concurrent_Versions_S ystem [wikipedia.org] has prooven itself to be superior and far more intuitive.

You have code that many projects share, like multi-platform-compatibility-layers? Just use symbolic links and CVS will follow them.

In SVN you have to create a repository for these shared source files and write config files by hand to make it include these files your repository.

I hardly see SVN reach the point of flexibility CVS has. They support Windows (which doesn't have symbolic links) and give up usability.

Except this difference SVN and CVS are the same. There are marginal differencies in features but these affect no real world use. So if you want a version control system where you don't need to write config files by hand you choose CVS. If you want the latest hype you choose SVN.

There wasn't really a need for SVN.

Re:SVN will not replace CVS (IMO) (4, Informative)

scribblej (195445) | more than 6 years ago | (#19243617)

You ever try to move a directory structure full of source code from one place to another in CVS -- or even to move or rename a single file...?

HINT: When you do it the way CVS provides, you will lose all of your revision history.

SVN does not have this fatal flaw.

Re:SVN will not replace CVS (IMO) (0, Troll)

mountie (461862) | more than 6 years ago | (#19243897)

Headline:

SVN Fixes an implementation flaw of CVS, worsens others, completely ignoring the big picture!

Re:SVN will not replace CVS (IMO) (1, Informative)

Anonymous Coward | more than 6 years ago | (#19243905)

You ever try to move a directory structure full of source code from one place to another in CVS -- or even to move or rename a single file...?

HINT: When you do it the way CVS provides, you will lose all of your revision history.

SVN does not have this fatal flaw.


What the hell are you talking about? You just log into the CVS server and move the directory/file in the repository.

Having to write config files by hand to route around non-existant symbolic links support on a platform that does support symbolic links is what I call a "fatal flaw".

If SVN is so great... why is the majority not using it? It's not like it is entirely new.

I can tell you why. Because developers are still angry with that wet-script-kiddie-dream-called-autoconf it selfimportant complaints about M4-here and can't-find-AC_blablabla-there. They don't want to run into the next selfimportant barrier on their way to actually get their project done. CVS just WORKS! For many years now. And if you have problems moving files/directories because your project is hosted on SF then that's the consequence of your choice and not CVS's fault.

But maybe it's more about configuring the projects development environment these days than getting work done.

Re:SVN will not replace CVS (IMO) (2, Insightful)

Vellmont (569020) | more than 6 years ago | (#19244195)


If SVN is so great... why is the majority not using it? It's not like it is entirely new.

Momentum for the most part. CVS is good enough 95% of the time, so it takes some reason to change over. I've recently started using svn after using cvs for years. I'm still not as familiar with svn as I am with CVS.

Personally I don't really like the different branching/tagging behavior in subversion, but I also think I just don't know it as well. Someday I'll have to find some decent documentation on how to use it properly.

Re:SVN will not replace CVS (IMO) (5, Informative)

Crazy Taco (1083423) | more than 6 years ago | (#19244439)

For many open source projects, finding good documentation is hard. In the case of Subversion, it couldn't be easier. In fact, the Subversion team has taken documentation to such a level that they should be considered THE model for documentation in the open source community. They have written a book (published in print by O'Reilly, but maintained and posted for free by them on the Internet) that documents their system, and it is very good. My job at the last company I worked for was to write wizards for the Eclipse platform that would automate several of the most common tasks that a Subversion user would try to do, and that book was the only reference I needed. You can find the book on their site here: http://svnbook.red-bean.com/ [red-bean.com] . They even do nightly builds of the book, so not only is their documentation complete and useful, it is also incredibly thorough and up to date.

If anyone on here hasn't read it, DO IT, because the first half will teach you why you want Subversion rather than CVS or some other alternative, and how to use it and how to get the most out of it (second half is lower level stuff you may not care about). It even includes best practices. Once you really learn how to use Subversion, you won't want to use anything else. And this is the way to get started.

Re:SVN will not replace CVS (IMO) (4, Interesting)

Crazy Taco (1083423) | more than 6 years ago | (#19243939)

And you can ALSO save space by version controlling ANY type of file because of its binary delta features. My software team often would place .doc files or other sorts of documentation into our projects, and CVS would save full copies of each document to version control them, chewing up space like crazy. If you work on a big software project, where you can run into things like 1000 page word specification files, you do NOT want a version control system that doesn't use binary differencing. This is another reason why SVN WILL replace CVS.

Re:SVN will not replace CVS (IMO) (1, Interesting)

Anonymous Coward | more than 6 years ago | (#19244081)

You ever try to move a directory structure full of source code from one place to another in CVS -- or even to move or rename a single file...?
HINT: When you do it the way CVS provides, you will lose all of your revision history.
SVN does not have this fatal flaw.


Yeah, that is a problem with CVS. Your revision history is there, you just can't trace it since a move is a delete and recreate. So if in your move/rename commit comment you say where you are moving it from, you can manually trace (though this is a huge pain).

We have moved all our CVS repositories to SVN at work. As much as I like the revision history problem being gone, I would've pushed harder to stick with CVS (I didn't think SVN was ready at the time, and I still don't). CVS is way more stable, solid, and trouble free, and clients for it are also very stable. SVN has numerous issues that keep popping up, mostly in the clients (the working copy metadata gets corrupted all the time), but some that might even be server-side corruption (didn't quite figure out why, but everyones' working copy got corrupted in the same place).

Are there any SVN-to-CVS conversion utilities out there for those of us who want to go back to CVS?

Re:SVN will not replace CVS (IMO) (1)

gbjbaanb (229885) | more than 6 years ago | (#19245263)

the biggest flaw with CVS is the fact its a client->files system, ie your client writes data directly to the repository. If you lose your network connection halfway through writing... uh-oh. SVN fixes this by making it all a client-server model instead. It is better.

However, SVN does have soem disadvantages (and some say these are so bad its not worth using it). SVN only manages whole directories - you cannot operate on a single file, try checking out a single file and you'll find you cannot. SVN also has a strange tagging/branching system, based on a kind of 'symbolic link' system that is efficient, but seems to be an engineering solution to a problem that needs to be solved by something more intuitive to a human operator. (eg. you cannot 'tag' a set of files, you have to make a branch and name the branch to the tag you want, it is great back at the server, but useless from the client POV).

So, SVN is better is many respects to CVS, but it is worse is others, and unfortunately it is not the ultimate source-control system I wish it was.

(oh, and as for the article - good stats, but ultimately useless - what's the point of tarring your files and storing them just so checkins go faster. Now if he'd supplied a patch to the client that tarred all files you were checking in, and to the server to untar them before checkin now *that* would make an excellent article.)

Re:SVN will not replace CVS (IMO) (3, Insightful)

OverlordQ (264228) | more than 6 years ago | (#19243773)

Subversion fails to follow symbolic links that point to code that other projects share for the sake of a minority that still develops using Windows (which doesn't have real symbolic links).

I am an SVN newbie, but that kinda sounds like Externals [red-bean.com].

performance not the biggest problem (3, Interesting)

hpoul (219387) | more than 6 years ago | (#19243583)

for me performance is (currently) the least of my problems with subversion..
more that you lose changes without any warning or whatsoever during merging .. http://subversion.tigris.org/servlets/ReadMsg?list Name=users&msgNo=65992 [tigris.org] .. and noone seems to be too bothered..

(don't get me wrong, i love subversion .. and i use it for my open source projects.. but currently CVS is way better.. just because of the tools and a few unnecessary annoyances less)

Re:performance not the biggest problem (0)

Anonymous Coward | more than 6 years ago | (#19243645)

It has binary and that is a big no-no in the community.

Re:performance not the biggest problem (1)

PatrickThomson (712694) | more than 6 years ago | (#19243701)

Yes, because a bug report that's 9 days old is indicative of a deep flaw in the developer structure. You should have at least said you were the one who filed it in the interests of full disclosure. Anyway, it's safe practice to check in the trunk modifications before you merge.

Re:performance not the biggest problem (3, Informative)

eli173 (125690) | more than 6 years ago | (#19243965)

Anyway, it's safe practice to check in the trunk modifications before you merge.

I think you missed his point... he'd committed all his changes. The problem is that if you merge a file or directory deletion in, where that file or directory had modifications committed, Subversion won't tell you about the conflict, but will delete the file or directory including the new modifications.

You wanted to delete it, so who cares, right?

Subversion represents renames as a copy & delete. So now, you rename a file or directory, and do the same dance as above, and the renamed file or directory does not have changes that were made on trunk under their previous names. So renaming a file can re-introduce a bug you already fixed.

No big deal, the devs will fix it soon, right? Wrong [tigris.org] and wrong again [tigris.org].

That is the problem.

Re:performance not the biggest problem (1)

hpoul (219387) | more than 6 years ago | (#19244095)

exactly .. and.. my biggest complaint is.. that i actually recommended subversion to everyone who asked because of his cool advantage over CVS - the versioning of directories ... how cool is that .. you can move a file and still have all the history of the file.. so .. no problem with refactoring a big project..

after all .. it's one of the biggest features.. see http://subversion.tigris.org/ [tigris.org] "Subversion versions not only file contents and file existence, but also directories, copies, and renames."

well .. of course it all works great.. until you merge...

but as i said .. i'll keep using it for my smaller open source projects.. but i can't honestly recommend it to bigger projects for a company ..

Re:performance not the biggest problem (1)

PatrickThomson (712694) | more than 6 years ago | (#19244521)

Yes, but you've not actually lost any data, you can pull the deleted files out of the repository. So at worst it would reintroduce a bug you would be able to find and fix later - but who merges without checking it worked?

Re:performance not the biggest problem (1)

eli173 (125690) | more than 6 years ago | (#19244853)

Yes, but you've not actually lost any data, you can pull the deleted files out of the repository. So at worst it would reintroduce a bug you would be able to find and fix later - but who merges without checking it worked?

Reintroducing a bug is a very bad thing. And if you've only worked on projects with 100% test coverage, and automated execution of said tests, you're going to be in for a real rude awakening when you get a job.



Um... sorry, let me set this flamethrower down here, turn it off, and I'll just back slowly away...

Re:performance not the biggest problem (2, Informative)

LionMage (318500) | more than 6 years ago | (#19244903)

So at worst it would reintroduce a bug you would be able to find and fix later - but who merges without checking it worked?

What if the merges are done by someone who isn't familiar with all the code changes and the expected associated application behaviors? What if there are dozens or even hundreds of code changes in a branch being merged to trunk? What if your QA work is being done by people who are not developers and who have no involvement in the merge process?

These are not just hypothetical issues. I work on a team which espouses the agile methodology, and many times we've missed bug fixes in merges because of the way Subversion treats moves (copy + delete instead of truly changing the parent directory of a given file), or because Subversion's merge facility got confused (especially when changes were made both to the branch and trunk versions of a file).

Recently, I was put in charge of merging a branch to the trunk for my team's project, and discovered that some methods were duplicated because one of our programmers had deleted the original version of a given method, then pasted in a completely different implementation into a different location in the same source file. It was easy enough to catch this with Java classes (since they won't compile correctly if you have two instances of the same method signature in the same class), but JavaScript was a slightly different story...

Re:performance not the biggest problem (1)

hpoul (219387) | more than 6 years ago | (#19243977)

take a look at the issue tracker.. there it was reported as a problem with renaming directories (months ago .. not by myself)..
so there is an announcement that there might be better renaming support in svn 1.5 ..

anyway .. i haven't found a similar report for just the case of deleting directories.. (since renaming = copy + delete) .. so i figured i would ask in the forum (not a bug report btw.) if this is at least known .. but anyhow ..

you want to know other annoyances ? how about .. the need to store plain text passwords if you want to use svnserve ? (afaik this is also announced for 1.5)

What about git? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#19243637)

In short: Use git-svn

Long version: The fraction of a few speedup described in the article is blown away by the several orders of magnitude you get by using git. Then there are all the other goodies, like real branches and merges, git-bisect, and visualization with gitk. Subversion is just for people who are forced to use it, or those not exploring all their options these days.

Re:What about git? (2, Interesting)

koreth (409849) | more than 6 years ago | (#19244229)

Hear hear. git-svn makes Subversion tolerable. The only reason I'd ever choose native Subversion over a newer system like git or Mercurial is if I needed some tool that had builtin Subversion integration and didn't support anything else. Absent that criterion, IMO if you choose Subversion it's a sign you don't really understand version control too well.

Re:What about git? (2, Insightful)

javaxman (705658) | more than 6 years ago | (#19245753)

The only reason I'd ever choose native Subversion over a newer system like git or Mercurial is if I needed some tool that had builtin Subversion integration and didn't support anything else. Absent that criterion, IMO if you choose Subversion it's a sign you don't really understand version control too well.

What if you have a bunch of developers working with some ( unfortunately, let me say that ) Windows-only tools for historical reasons ? Are you really saying that I should have a team of VisualStudio users install cygwin on their systems ?

git is great for Linux kernel developers, but 'install this massive compatibility layer to use this product' will fail to make you a lot of friends, especially in a Windows-friendly corporate environment. I say that as an avid, daily CygWin user and longtime Windows hater. We could have maybe picked Mercurial, but a year ago when we looked, it didn't even hit our radar as a possibility.

Subversion has some little issues, but it's getting lots of attention, and the problems aren't bad. I'm a little suspicious that the performance claims of Mercurial might not be measuring apples-to-apples... an 'svn commit' is both an 'hg commit' and 'hg push', if you want to be fair.

Re:What about git? (1)

statusbar (314703) | more than 6 years ago | (#19245959)

Very interesting! Does git-svn work on Win32 and Mac OS X?

Newer schematic and circuit board layout programs support svn directly (via svn.exe on windows) - Would there be a git-svn.exe to replace the svn.exe with the same command line set?

--jeffk++

svn+ssh and master mode ssh. (4, Informative)

frodo from middle ea (602941) | more than 6 years ago | (#19243681)

My solution, use svn+ssh and keep a ssh connection to the svn server in Master mode. All svn+ssh activity tunnels through this master connection , no need for ssh handshake each time or for that matter no need to even open a socket each time.

Plus if the master connection is set to compress data ( -C ) , then you get transparent compression.

Now if only I could expand all this to fit 2 pages....Profit!!!

Use GForge or GForge/AS or customize them (1)

aisnota (98420) | more than 6 years ago | (#19243781)


Well if you use a customized version of GForge or the Advanced Server edition linked to some content engine or even someting more basic like NCftp at a professional level.

CVS and Subversion both work with GForge according to their web site.

Customized editions are available as far as I know. They have a roster of high end clientele, Cisco, MIT and others, so they must work pretty smart and well for people.

--

why import/export (1, Interesting)

Anonymous Coward | more than 6 years ago | (#19243785)

why use subversion only as import/export? That's the complaint here right? (the slow import/export speeds?) I thought the point in using revision control is to checkout then do commit/update commands???

Re:why import/export (1)

pearlmagic (1032966) | more than 6 years ago | (#19245931)

Amen to that. TFA was really missing some useful information. The only place I can see doing clean export/checkout is on a build machine where they need to guarantee there isn't anything leftover that could compromise the build. I'm one of the SVN admins at our company and this is something that we're going to have to keep an eye on.

Di3k (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19243789)

claim that BSD is a and Juliet 40,000 website. Mr. de

It may have performance problems, but... (5, Interesting)

Crazy Taco (1083423) | more than 6 years ago | (#19243879)

It is still the wave of the future. I've worked in it extensively, and it is still the best version control system I've ever used. Because of its other strengths, it is continuing to expand its user base and gain popularity. You can tell this because Microsoft is now actively attempting to copy Subversion's concepts and ways of doing things. Ever used Team Foundation Server? It is just like Subversion, only buggier (and without a good way to roll back a changeset... you have to download and install Team Foundation Power Tools to do it). I'm a new employee at my company (which uses Microsoft technology), and yet I've been explaining how the TFS system works to seasoned .Net architecture veterans. The reason I can do this? I worked extensively with Subversion, read the Subversion book a few times (the O'Reilly book maintained by the Subversion team), and worked on a project for my previous company that basically had the goal of making versions of the TFS wizards for Subversion on the Eclipse platform. It only took me about one day of using TFS to be able to predict how it would respond, what its quirks would be, etc, because it's technical underpinnings are just like Subversion. So even with performance issues, if even Microsoft is abandoning its years of efforts on Source Safe and jumping all over this, you can know that its strengths still make it worth adopting over the other alternatives. After all, if Microsoft was going to dump source safe, it had its pick of other systems to copy, as well as the option of trying to make something new. What did it pick? Subversion.

Re:It may have performance problems, but... (4, Interesting)

GrievousMistake (880829) | more than 6 years ago | (#19244577)

Honestly, if you think Subversion is the wave of the future, you haven't been paying much attention. It fixes some fundamental flaws in CVS, which is nice, but elsewhere there's exciting stuff like Monotone, darcs and many others. It seems people aren't looking hard enough for source control options, when they'll go wild over things like SVN, or more recently GIT.

I suppose one has to be conservative with deployment of this stuff, you don't want to have code locked away in unmantained software, or erased by immaturity bugs, but it's still an interesting field.

Re:It may have performance problems, but... (1)

Crazy Taco (1083423) | more than 6 years ago | (#19244831)

I do agree, and I'm open to experimentation, but I've used SourceSafe, Team Foundation Server, ClearCase, CMVC, CVS, and Subversion, and I've found Subversion to be the best by far, as well as very reliable. Is Subversion absolutely the best out there, or the very best system possible? Perhaps not, but the problem is that there are so many systems out there, and so many of them (nearly all) are inferior, that you can't be suprised or blame people for jumping for joy at Subversion and becoming huge fans. I think people (myself included) are getting tired of having to keep searching for a better version control system. CVS was good, but it had some pretty big flaws that Subversion fixed. Subversion made a good version control system great, and I think most people will probably start using that long term just liked they used CVS long term until a major reason to switch comes along. Subversion is familiar (if you've used CVS), stable, well documented and fully featured. Are other systems better? Possibly, but Subversion is so good that the marginal utility of switching to yet another new version control system is pretty low, especially given Subversion's edge with users in the area of familiarity.

Re:It may have performance problems, but... (1)

cching (179312) | more than 6 years ago | (#19245507)

You should really have a look at monotone. Better quality code and features you'd probably only *dream* about. They're a bit slow on getting to that 1.0, but it's a very solid RCS right now. I'm piloting it where I work for a project, hopefully I can convince my team to adopt it. The only shortcoming I'm running into right now is the toolset that we've built/found based on CVS (Bonsai, Codestriker, and some others). I just can't match those yet.

Re:It may have performance problems, but... (0)

Anonymous Coward | more than 6 years ago | (#19245681)

For me, one of the most useful features of Subversion is its ability to act as a plugin to Apache. This lets me integrate it into my company infrastructure very easily (HTTP/s protocol, LDAP authentication, etc). I see monotone is more of a distributed rcs, how well does it implement these types of features when acting as a server?

Re:It may have performance problems, but... (1)

cching (179312) | more than 6 years ago | (#19246177)

It doesn't act as a server, it truly is a distributed RCS. Yes, you probably want a central repository where you do integration and builds, but that's a CMS issue, not an RCS issue.

As for being able to pull over HTTP, that isn't in, but I think it's been discussed. Honestly, though, I don't find the need to pull over HTTP that important, but, of course, your needs vary. I'm just tired of being tied to a central repository in order to do commits. I work disconnected a lot and monotone fits the bill. Not to mention we have distributed developers who complain all the time of the need to connect to a central repository to do simple commits.

Re:It may have performance problems, but... (1)

maxume (22995) | more than 6 years ago | (#19245965)

None of the tools you mention are 'distributed', they are all 'hosted'(to host a distributed repository, you generally just put it somewhere). Svk is supposed to be pretty nice, and it knows how to talk to subversion, so you get the best of both. I use bazaar for a bunch of small projects, it's great, fast enough, backing up is as simple as copying the directory..

Re:It may have performance problems, but... (1)

XO (250276) | more than 6 years ago | (#19246405)

I am pretty frustrated with Subversion, and all I do is manage a few pieces of source code with it. It's always farking my things up, it seems. Well, at least once a month or two, I'm mucking around with the internals of the repository to fix crap that svn did.

Also, SVN doesn't -have- a way to rollback.

Oh thank god (0, Troll)

Richard McBeef (1092673) | more than 6 years ago | (#19243895)

My version control system is so fucking slow. It pisses me off to no end. I mean I'm all like trying to check stuff in and it takes forever. Thank god someone took the time to speed these bitches up.

Store them differently (4, Interesting)

Tankko (911999) | more than 6 years ago | (#19244025)

I've been using Subverison for 2 years on game related projects. Most of our assets are binary (photoshop files, images, 3D models, etc), plus all the text based code. I love subversion. Best thing out there that doesn't cost $800/seat.

What I don't like about this article is that it implies I should have to restructure my development environment to deal with a flaw in my version control. The binary issue is huge with subverison, but most of the people working on subversion don't use binary storage as much as game projects. Subversion should have an option to store the head as a full file, not a delta, and this problem would be solved. True, it would slowdown the commit time, but commits happen a lot less than updates (at least for us). Also the re-delta-ing of the head-1 revision could happen on the server in the background, keeping commits fast.

What's wrong with version control? (4, Interesting)

shirai (42309) | more than 6 years ago | (#19244091)

Okay, I know this is completely off-topic but I'd really like to get some responses or some discussion going on what makes version control suck.

I mean, is it just me or is revision control software incredibly difficult to use? To put this into context, I've developed software that builds websites with integrated shopping cart, dozens of business features, email integration, domain name, integration, over 100,000 sites built with it, (blah blah blah) but I find revision control HARD.

It feels to me like there is a fundamentally easier way to do revision control. But, I haven't found it yet or know if it exists.

I guess for people coming from CVS, Subversion is easier. But with subversion, I just found it disgusting (and hard to manage) how it left all these invisible files all over my system and if I copied a directory, for example, there would be two copies linked to the same place in the repository. Also, some actions that I do directly to the files are very difficult to reconcile with the repository.

Since then, I've switched our development team to Perforce (which I like much better), but we still spend too much time on version control issues. With the number, speed of rollouts and need for easy accessibility to certain types of rollbacks (but not others), we are unusual. In fact, we ended up using a layout that hasn't been documented before but works well for us. That said, I still find version control hard.

Am I alone? Are there better solutions (open source or paid?) that you've found? I'd like to hear.

Re:What's wrong with version control? (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19244323)

I mean, is it just me or is revision control software incredibly difficult to use? To put this into context, I've developed software that builds websites with integrated shopping cart, dozens of business features, email integration, domain name, integration, over 100,000 sites built with it, (blah blah blah) but I find revision control HARD.

Have you considered the possibility that you're just retarded?

Re:What's wrong with version control? (3, Insightful)

Cee (22717) | more than 6 years ago | (#19244451)

Yes, version control is more difficult than not using any tool at all, but that goes for most stuff in life. There are certainly areas where usability can be improved.

Fiddling with stuff you are not supposed to fiddle with is generally a no-no when using source control. I found though that I got used to the Subversion way to do things (learned that the hard way). For example Subversion on the client side does not really handle server side rollbacks of the complete repository since the files are cached and hashed locally. One way to make source control more transparent to the user could be to let the filesystem handle it.

Re:What's wrong with version control? (1)

greed (112493) | more than 6 years ago | (#19245487)

Rolling back the repository on the server is a very, very bad idea unless you're recovering from a major "OH DAMN!". Much better, in Subversion, is to just copy the old, good one that you want to the latest version, then the clients will know to update.

CVS can get so badly lost you have to manually hack the entries file if you start making revisions vanish on the server.

Re:What's wrong with version control? (2, Interesting)

0xABADC0DA (867955) | more than 6 years ago | (#19245725)

But that's the problem with subversion... the things that one might normally do all the sudden are 'fiddling with stuff you are not supposed to fiddle with' and a big 'no-no'.

1) You want to make a copy of trunk to send to somebody:

    tar cvf project.tar .

With svn you have to go through a bunch of magic to do this or you end up giving them an original copy when you may have local changes (you tweaked some config option or whatever), your username, time svn repo address and structrure, etc. If you do svn export it makes a copy of what is in HEAD not in your folder, so there is no way to do this without going back and weeding out this junk

2) You want to export something

    # svn export svn:something /tmp
    svn: '/tmp' already exists

Really, you think?

3) You make a copy of a file and then decide to rename it (or other cases).

    # svn cp /other/file.c file.c
    # svn mv file.c newname.c
    svn: Use --force to override
    svn: Move will not be attempted unless forced
    # svn --force mv file.c newname.c
    svn: Cannot copy: it is not in repo yet; try committing first

Svn says you *must* do a bogus commit because you wanted to rename a file, or alternatively you can revert the new file and lose it? wtf? dumb.

4) You want to do the same thing on lots of files

    # svn mkdir newdir
    # svn cp *.c newdir
    svn: Client error in parsing arguments

That's right you have to break out your bash/perl script skills to do this. Lame.

There's a *lot* to dislike about svn. It's basically just 'icky' all throughout. The checkouts are huge and ugly, many operations are slow (compared to monotone), its really annoying to have a private repo that you sync occasionally so you end up with zillions of tiny commits or losing work because you didn't commit enough. And the repo itself is very large -- converted a 2g repo from svn to monotone preserving revisions and even with straight add/del instead of renames/moves the monotone database was a small fraction of the size, about 1/6th. Incidentally, the monotone version was much faster in pretty much every way.

Monotone is technically much better than subversion, except for one problem that you can't checkout only a subset of a repo. Maybe they have fixed that by now and if so it would be crazy to use svn instead of it IMO. I'm sure there are also many others out there better than svn.

Re:What's wrong with version control? (2, Interesting)

norton_I (64015) | more than 6 years ago | (#19244529)

You are not alone, but I think the problem is intrinsic (or nearly so). VC is one more thing you have to worry about that is not actually doing your work. It is easy as long as you don't want to do anything with VC you couldn't do otherwise. If all you do is linear development of a single branch, it is pretty easy. Memorize a few commands for import, checkout, and checkin and you are fine, but all you really get is a backup system. As soon as you want to branch and merge and so forth, it becomes much more complicated.

I think the only way to make it work really well is to have an administrator whose job it is to be a VC expert, rather than a programming expert. You need someone with some serious scripting skills and a deep understanding of the structure of the VC filesystem. With the proper scripts in place, you can really streamline the process for your specific project and enforce your coding practices, but maintaining the system is a seperate skill from programming. Also, when performing non-standard merges or whatever, you would probably need a coder to work with the admin to make sure you don't do it in a way that will hamstring you later. Of course, most projects can't afford that, and many programmers don't want to leave their code in the hands of some script monkey, or won't believe that someone else can do something as "trivial" as vc better than them :)

Re:What's wrong with version control? (2, Insightful)

jgrahn (181062) | more than 6 years ago | (#19245447)

You are not alone, but I think the problem is intrinsic (or nearly so). VC is one more thing you have to worry about that is not actually doing your work.

If it isn't about doing your work, then why do you do it?

Of course it is about doing your job. If you're a programmer, it's analogous to asking your C compiler not to suppress warnings. You would have to find those bugs anyway, and you would do a much worse job without the help.

In my work, version control (or whatever fancy name ending in "management" you like to put on it) relieves me of enormous burdens. It lets me do separate work in isolation. It lets me plan and replan my work, reschedule so that feature B gets delivered before feature A. It lets me review other people's changes, and it lets others review mine. It lets me track the root cause of a bug, created years ago. It lets me know exactly what I delivered to some poor guy.

Note though that you need more than a tool. You need to have a common view on how to use it in your environment.

And you cannot have people who think it's useless non-productive non-work, because they won't care -- and quite soon they will turn it into useless non-productive non-work by taking "a few shortcuts" which negate all the positive effects of version control, making it analogous to wearing an expensive Armani suit and leaving the fly open.

Re:What's wrong with version control? (0)

Anonymous Coward | more than 6 years ago | (#19245475)

"VC is one more thing you have to worry about that is not actually doing your work".

If that is true for your work, you should not use version control. However, keeping a trail of what they did and why, and clearly tagging releases _is_ actually doing their work for many people, and it probably should be for even more of them.

Re:What's wrong with version control? (1)

jayp00001 (267507) | more than 6 years ago | (#19244769)

Nope, version control in general stinks. MS Team foundation server is an attempt to make it easier because Microsoft controls both client and server aspects. I'd say they were marginally successful in making it easier than a seperate version control system. Alot of the problems stem from the fact that version control should be invisible and isn't and many people have different ideas about version control. You mentioned that perforce allowed you to directly make changes to files and later reconcile them. Generally speaking that's a version control nightmare (as it's expected tht you check in and check out copies) and many users do exactly that.

Re:What's wrong with version control? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19245013)

You mentioned that perforce allowed you to directly make changes to files and later reconcile them. Generally speaking that's a version control nightmare (as it's expected tht you check in and check out copies) and many users do exactly that.

You sound like someone who's only used to the VSS way of doing things. Lock-Edit-Release. Try this with a parallel development shop where different teams are on different continents, throw in production support and bug fixing, and you'll quickly see where the true nightmare lies. (Especially if you don't do any branching or tagging)

SVN/CVS users normally do optimistic locking, i.e. Copy-Edit-Merge.

I personally prefer to have my local copy completely disconnected from source control, allowing me to edit files willy-nilly. (maybe to test some changes or do some debugging)

Generally speaking, it's only a nightmare if you don't know what you're doing, or don't know how to merge.

What do you find hard? (1)

sheldon (2322) | more than 6 years ago | (#19245323)

In it's simplest form... just keeping a history of changes, it really isn't that bad.

where it becomes complicated is when you start talking about branching, merging, or trying to deal with dependencies across projects, etc.

But if done well, version control helps more than hurts.

Re:What's wrong with version control? (2, Interesting)

tentac1e (62936) | more than 6 years ago | (#19245783)

It's difficult because of the inherent complexity of the problem. Version Control is recording and syncronizing changes to an arbitrary set of files in an arbitrary file hierarchy. Everything is easy until you start messing with the layout, but that's just a matter of using "svn" instead of doing it by hand.

A lot of people use version control without understanding it. I just took a side gig to replace an incompetent developer who spent 7 months developing a web app directly on the server. One of his last acts was to put the project under subversion. The idiot put 35 megs of logs into the repository.

Why should you care about those invisible files in your directories? If you want a clean copy without those directories, do an "export." If you're messing with those files on a working copy, you deserve every minute of pain.

Why would you copy a folder directly? If you want to experiment with a change, either commit your current change and experiment on your working copy, or create a branch. That sounds complicated, but the learning curve is about the same as using "history" in photoshop.

What's so unusual about your team? My deployments and rollbacks take seconds via Capistrano [rubyonrails.com].

Re:What's wrong with version control? (0)

Anonymous Coward | more than 6 years ago | (#19245947)

Is it just me or do computers suck? To put this into context, I've written 3 novels with pens and typewriters, but I find word processors HARD.

More about tuning your processes (3, Informative)

weinerofthemonth (1027672) | more than 6 years ago | (#19244247)

Based on the headline, I was expecting some great method for tuning Subversion for increased performance. This article was about performance tuning your processing, not Subversion.

Storing binaries in revision control is good ... (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19244857)

...but storing them in delta format is worthless. I've been a source control and build engineer for over a decade, and yes I store binaries in my repository. But only third-party binaries, like libraries. Generated files, such as libraries built from our source code, do not belong in source control. Store the source, generate the binaries.

Because disk space is nearly free, storing files in delta format no longer meets the original need, which was to decrease disk usage. But revision control systems were built on delta storage, which is actually a good thing in that syncing your workspace to the repository, or diffing revisions, is easy and quick because the system doesn't need to create the diff or send the entire file. Just send the diffs and apply them to the workspace. In short, a file's revision history is a history of the successive differences, so of course we want to store them as a diff chain.

But what about your compilers, linkers, and other tools? Store them in revision control? Third-party libraries change rarely enough that we all can afford both the disk space for full copies or successive revisions to be stored, and the time it takes to upload or download the entire package. Tools usually change less frequently. In both cases, I do not trust any revision control system to correctly patch my compiler or other binaries based on what it thinks the diffs are. If there's a bug in the system, how would you know? At least with plain-text files, a human can look at the differences and decide if they are correct.

And what about binary source files? You know, MS Office files, CHM files, and anything else which is not stored on disk in the same way it's presented in the authoring tool. If for example you store a Word DOC as successive diffs, but not everyone is using the exact same version of Word (on the exact same OS), or everyone is using the same version, but at some point in the file's lifetime that version changes, you're basically screwed. Use revision control for the benefits of centralized storage and labeling, but save yourself a migraine and always save full revisions.

And now, my recommendation to use Perforce: Not only is it a great product, but the technical support there is the best of any company I've ever dealt with, for any product in any industry, on any planet in any universe.... OK, you get the point. Time for more coffee.

Is this a solution in search of a problem? (0)

Anonymous Coward | more than 6 years ago | (#19244939)

Disk space is stupidly cheap.

Developers will not do these workarounds (3, Informative)

javaxman (705658) | more than 6 years ago | (#19245089)

At least in a general case, I couldn't expect the developers I work with to gzip their binaries before checking them into version control.

Doing so means you have to unzip them to use them. Not very handy. Most users want to use Subversion the way they should be able to use version control- a checkout should give you all of the files you need to work with on a given project, with minimal need to move/install pieces after checkout. Implementing the 'best' suggested workaround would mean needing a script or other way to get the binaries unpacked. Programmers are often annoyed enough by the extra step of *using* version control, now you have to zip any binaries you commit to the repository?

I'm unimpressed by their performance testing methodology... they give shared server and desktop performance numbers, but have no idea what 'else' those machines were doing? Pointless. I'd like more details regarding what they're doing in their testing. Their tests were done with a "directory tree of binary files", but don't say what size or how many files?

My tests on our server show a 28MB binary checkout ( LAN, SPARC server, Pentium M client ) takes ~20 seconds. Export takes ~2sec. That must be a big set of files to cause a 9 minute *export*... several gigs, am I wrong? It'd be nice for them to say. Most of us, even in a worst case, won't have more than a few hundred MB in a single project.

The only *real* solution will be a Subversion configuration option which lets you say "please, use all my disk space, speed is all I care about when it comes to binary files". CollabNet is focused enough on getting big-business support contracts that it shouldn't be long before we see this issue addressed in one manner or another. You -know- they're reading this article!

Re:Developers will not do these workarounds (1)

Crazy Taco (1083423) | more than 6 years ago | (#19245231)

My tests on our server show a 28MB binary checkout ( LAN, SPARC server, Pentium M client ) takes ~20 seconds. Export takes ~2sec. That must be a big set of files to cause a 9 minute *export*... several gigs, am I wrong? It'd be nice for them to say. Most of us, even in a worst case, won't have more than a few hundred MB in a single project.

What you say is true, but the problem is that that isn't how any organization I've seen tends to use Subversion (or Subversion like) version control systems (TFS comes to mind). What they typically do is have a root directory in the repository, and the roots of ALL projects are stored under that. Therefore, every project in the organization is in the same file tree in the Subversion repository. Most all of those projects are probably pretty small like yours, but all of them combined can be equal to many gigabytes of space. Despite these performance issues, most organizations still need that sort of structure so that they don't have tons of repositories sitting around. This way, they only have one repository and they can store every single project in it. But unfortunately, this is also where the performance hit comes in.

For those using Subversion (or TFS) at most organizations, you can see what I mean by looking at the revision or changeset (check in) numbers. Check something in. Note the number. Wait about an hour without checking something in. Look at the repository's latest revision. Odds are, the revision number has gone up. Why? Someone else on some other project stored in some other folder out on the tree checked something in, and the repository keeps track of binary deltas of the entire tree! That's a good thing because that is what lets you move and rename files without losing their history (even changing the name of your project or moving it), but again, it is also how you get gigabyte upon gigabyte into the repository and start crippling performance.

Re:Developers will not do these workarounds (1)

pearlmagic (1032966) | more than 6 years ago | (#19245451)

The performance hit for having everything in one repository "shouldn't" be as bad as you think. Each revision is it's own separate file, and determining which files have changed in that set is very minimal, so doing an update on your repository when some other project checked something in should be negligible, as files in your project didn't actually change. Of course larger repositories will start to take longer doing checkouts/exports, and project "cleansing" should always be the first line of defense in these performance hits. TFA didn't at all talk about update/commit at all, which is what people should be using instead of checkout/export. If they did that, the performance hit would go away suddenly I think. He also didn't say which DB backend it used (BDB or FSFS).

Vesta is better (3, Interesting)

ebunga (95613) | more than 6 years ago | (#19246111)

If you actually care about your code and making proper releases, use Vesta [vestasys.org]. Transparent version control that even tracks changes between proper check-ins (real "sub" versions). Built-in build system that beats the pants off of Make. It even has dependency tracking to the point that you not only keep your code under version control, but the entire build system. That's right. You can actually go back and build release 21 with the tools used to build release 21. It's sort of like ClearCase but without all the headache. Did I mention it's open source?

The first time I used Vesta, it was a life-changing experience. It's nice to see something that isn't a rehash of the 1960s

Notice.. (2, Interesting)

sudog (101964) | more than 6 years ago | (#19246433)

.. that the article is glaringly absent *actual check-in times.* Or, where *actual check-in times* are available, the details of whether it's the same file as in previous tests is glaringly absent. This leaves open the question as to whether the data set they were working on was identical or whether it was different between the various tests.

Questions that remain:

1. Does the algorithm simply "plainly store" previously-compressed files, and is this the reason why that is the most time-efficient?
2. What exactly was the data for the *actual check-in* times? (What took 28m? What took 13m?)
3. Given that speedier/efficient check-in requires a large tarball format, how are artists supposed to incorporate this into their standard workflow? (Sure, there's a script for check-in, but the article is absent any details about actually using or checking-out the files thus stored except to say it's an unresolved problem regarding browsing files so stored.)

The amount of CPU required for binary diff calculation is pretty significant. For an artistic team that generates large volumes of binary data (much of it in the form of mpeg streams, large lossy-compressed jpeg files, and so forth) it would be interesting to find out what kind of gains a binary diff would provide, if any.

Document storage would also be an interesting and fairer test. Isn't .ODF typically stored in compressed form? If not, then small changes wouldn't necessarily affect the entirety of the file (as it would in a gzip file if the change were at the beginning) and SVN might be able to store the data very efficiently. Uncompressed PDF would certainly benefit.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...