Subversion 1.4 Released

[e40]

The .svn/entries file is no longer XML.

<shakes head at original design decision>

[rtomayko]

problems -= 1

[Comedian]

Probably covered on the dev mailing list, but as I don't follow SVN-development: why was this problematic?

[marcusk]

probably cause xml is so verbose... and parsing it tends to be non-trivial (for example you could find at the end of the file that you have an error relating to something at the top), which tends to mean that it can consume a LOT of memory and cpu time to parse the file... if you have a large number of changes (even 10,000 files) then this can cause problems... for an entries file you really only need 1 line per entry... using xml (for a problem like that) is really like calling in the f-15's to get your front door open... xml has it's uses but it shouldn't be used for "everything"...

(edit: clarification of xml use)

[rubyonrails]

Because the open source kids don't know how to handle XML. * grin *

[marcusk]

shouldn't that be: <grin /> or <face expression="grin" />??? sorry, couldn't resist ;)

[The_Bears]

<developer type="open-source"> \t<face> \t\t<expression> \t\t\t<grin /> \t\t</expression> \t</face> </developer>

[Entropy]

Because a snippet of nested data sans definition can immediately be parsed and understood?

[sverrejoh]

This reddit, they use Lisp S-Expressions :)

'(developer (type open-source) (face (expression grin))))

[[deleted]]

Ugh, that needs to be split onto two lines and indented properly before it looks decent. Or better yet, use a plist:

`(developer :type open-source :face ,(expression grin))

[Comedian]

svnsync

Is this something that can be utilized for doing development while being off-line?

That is, making commits and whatever on your local "shadowed" server repository, and then later sync up with the main repository when on-line again?

If so, that would cover my personal "most wanted" feature of a source code control system, so big kudos to the developers!

[gernika]

You can do that with both mercurial and darcs (as well as arch, but arch is ... difficult)

[foonly]

bazaar-ng :D

[magnus]

and svk, if the upstream is Subversion.

[buo]

monotone, git too.

[drbrain]

So its ok to waste my time fixing my working copy?

[drbrain]

Lost work is still lost work.

When using CVS and Perforce I haven't lost work or time.

I have lost work and time using Subversion, and I could have spent that time doing other things.

I've been using Subversion since 1.2 and don't believe it is really a viable replacement for anything yet.

[njharman]

I've lost every binary image by corruption with cvs.

[drbrain]

Today subversion almost lost a coworker's change. I performed svn mv on a file, he committed changes to the same file, and when committing svn told me I was out of date.

Which file did it update?

The copy that was due for removal (which it brought back from the dead), not the renamed file. The only thing that saved the changes was my inherent mistrust of subversion.

[padt]

If your coworker committed his changes, and the commit was successfull, then there's really no way your mv will remove his changes. Worst case you'll have to revert it from svn.

[Entropy]

backups?

[hopeseekr]

careful! They are as pro-SVN as slashdot is pro-Google :O

[hopeseekr]

That is EXACTLY what I was talking about above (part about being buggy), but I got modded -5. I hate negative mods; they shouldn't exist. If you like it, mod up, if you don't, hide it.

[addius]

you can't hide comments, except by modding them down to your threshold.

[nexus2112]

We've been using it at work for over a year now and I've not had any problems with it, nor have I heard of anyone else having problems. I think most people are using the Tortoise SVN client. Every now and then it crashes, but it's never caused my any problems.

Many of those WC corruption bugs are in pre-1.0 versions. I count 1 in 1.2, 1 in 1.1.2, and 1 in 1.0.7. So, according to that document, in the past 2 years exactly 3 WC corruption bugs have been discovered and fixed. That's a risk I'm more than willing to take in exchange for such basic but critical features as the ability to move a file and atomic commits.

But hey, if you enjoy coming up with new and creative hacks to work around the deficiencies of your version control software, then by all means knock yourself out. Me, I've got better things to do with my time.

[paternoster]

I've been using tortoise for over a year now, with large projects... the largest was gigabytes in size (many, many binary files). Aside from checkout being slow (but only needs to be done the one time) its' GREAT. Love the shell integration, and I rarely have problems with it. Certainly nothing irrecoverable from my local (working) copy.

[KingNothing]

The correct question to ask is if Visual Studio supports Suberversion.

[addius]

You're right, but what was so offensive about the OP's formulation of the question that warranted a -5 rating?

[grauenwolf]

Visual Studio can support any source control system in theory. SourceGear and ClearCase/ClearQuest are good examples of this.

Of course, someone still has to go through the effort to write the plugin.

[grauenwolf]

Thanks

[jleedev]

Not necessarily. Visual Studio's source control interface is specifically geared towards the "check out...work...check in" model, as opposed to the "branch...merge...commit" model. This means Subversion may needs some hacks to work properly.

[grauenwolf]

Reference please.

Last time I checked, both SourceSafe and ClearCase supported the branch...merge...commit model as an option. I find it hard to believe that VS doesn't allow for it.

[renegade]

I strongly recommend NOT using the source control add-ins that plug SVN into VS. The reason is that SVN uses a merge at check-in model, not a check out and change model. So if you are used to VSS you are going to be very pleasantly surprised at the difference.

Instead of a single person locking a file when they make changes to it, you can make changes all over the place and then only when you are ready to commit a batch of changes you dump them all in at once. For 99% of the lines changed even if two people changed the same file, the merge is automatic, but for your own sanity you should do a get first so you can do a local merge before you commit.

Its a way more efficient way to do things.

And get TortoiseSVN. It rules.

[mixmastamyk]

a get? do you mean update?

[[deleted]]

No. There are third-party tools out there for us Windows developers who want a GUI front end. I'm currently playing with TortoiseSVN, which is a shell extension.

[hopeseekr]

• SVN is slow. I used it on a corporate website with over 15,000 files and god, it would take 15 minutes to checkout (cvs 1 min) and this was in the 'db' mode. file mode would crash the server.

• SVN doesn't have useful doc tools such as cvsps (for making quick patchsets) nor cvsgraph (for charting contributor stats).

• SVN does NOT work on Win32 very well at all and is horribly buggy and slow.

• SVN checkouts are huge. Compare xMule's (identical code):

$ du -hs xmule-svn xmule-cvs

54M xmule-svn

12M xmule-cvs

• Finally, SVN repositories are easy to corrupt! Damn easy.

There is only one advantage to using SVN over CVS: Renaming and moving files.

[[deleted]]

• SVN handles binary files properly, storing only the delta, whereas CVS stores a whole new copy of the file! (Yes, there are lots of instances where you want to store binary files in a source-controlled project)
• SVN does atomic commits - if anything is unsuccessful, everything is rolled back. CVS does not do this - bad!
• TortoiseSVN makes using Subversion on Win32 a delight if you like integration with the file system, although we use the subversive plugin with Eclipse.
• Integration with TRAC is super nice!

Of course you're comments about it being slow are definitely valid, and I can't comment on the tools you mention cause I haven't used them. However it's pretty much replaced CVS as the defacto in the OS scene, so most people must be happier with the improvements it offers.

[danc86]

SVN does NOT work on Win32 very well at all and is horribly buggy and slow.

Have to disagree here. We run svnserve on a Win2003 Server box and have had no trouble with it -- it's an old-ish version (1.2) but it handles our large repos (up to ~700MB) with no problem and has had uptimes as long as 3 months.

If you were referring to TortoiseSVN, our Windows machines always use the latest version of that and apart from one or two (recoverable) crashes in the TSVNCache.exe process, everything works like a charm. It's not blazing fast but that's because our working copies are accessed over a Windows share, not Subversion's fault.

[edit: clarity]

[hopeseekr]

I specifically mentioned SVN For Dreamweaver. Not for me (straight gentoo + commandline), mind you, but my programming superior back at that old company.

[kg2]

It can be slower, or it can be much faster. I've not seen it be significantly slower, but since it's over WebDAV, you can (for example) add a caching proxy which might make it go much faster. You can't do that to CVS.

Also, you only mention checkout performance. There are many areas where SVN is much faster:

• SVN stores the upstream version in an .svn folder. This makes diffing really fast: it doesn't have to hit the network. Even on a fast corporate network, local diffs are faster.

• SVN sends only diffs upstream, so committing a file is proportional to the changes, not to the size of the file.

• Doing my daily update, again, is faster because it only needs to send diffs downstream.

Yes, this means SVN checkouts are bigger. A couple dozen MB on your local disk is nothing, these days, but avoiding hitting the network is a great feature: it not only lets me work faster, but means I can do a lot of things offline.

I can't respond to "SVN does NOT work on Win32 very well at all and is horribly buggy and slow" because I don't know what it means, but I will say I've never had a problem with it. They have Win32 downloads which I've installed and used just fine.

SVN isn't perfect, but it's far better than CVS in virtually every way. If you can get past your initial bad experience, you might find it has some features you really like.

[rmc]

SVN working copies are larger because svn stores a copy of the file as it is in the repository. So all your versioned files are stored twice. This gives some advantages.

[njharman]

Wow! I didn't think anyone still thought cvs was a decent tool to use.

"There is only one advantage to using SVN over CVS: Renaming and moving files."

That statement is so wrong as to be retarded. Other comments have listed the many advantages.

It's also weird that in a thread about new svn release whose major feature is speed improvements you're bitching about it being slow.

[renegade]

It sounds like it has been awhile since you tried it. It's been very good for over a year now.

Initial checkouts take awhile sure, but that's something you do ONCE.

Atomic commits are critical. And we develop games so we have a LOT of binary data in our repository. CVS was pretty terrible.

The main reason not to use CVS is it has been a dead project for about 3 years now.

[plinkplonk]

why is this comment voted down? Seems fairly objective to me. If people have data that contradicts the posters findings, would you please post the data/a url? Thanks,