Ease Into Subversion From CVS

Tip by aePrime · 2004-03-07 16:14 · Score: 3, Insightful

Remember, when changing software components, it's a good idea to back up first!

Is there demand? by cookiepus · 2004-03-07 16:29 · Score: 4, Interesting

I've read the linked article (really!) and I think Subversion sounds like a good idea. Primarily, I like the fact that everything you can do with CVS you can do with Subversion in the same way as with CVS.

I am really curious how much demand there is for Subversion's new features, however.

Do developers out there voice the need to store binaries? I can imagine this being needed for web developers and such, but I think programmers can just build their binaries from CVS.

Also, have there been many problems that required atomic commits? Can someone explain why this is important? I mean, the idea is you'll need to merge one way or another. I can see the point being in that what you commit at any given time will compile (presuming you're commiting completed code) but realistically, does anyone not fix their up-to-date checks as soon as they happen?

Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...

To me it sounds like a great product but I am not able to see a compelling reason why most development shops out there who are currently in CVS would rush to switch.

Not a flame btw, just an opinion.

--
Ecce Europa - Web Design for Business

Re:Is there demand? by nosferatu-man · 2004-03-07 16:35 · Score: 5, Informative

We're switching. CVS is crufty, buggy, and slow. That alone is reason enough to switch, but atomic commits and faster and more transparent branching will be, in the long run, a more fundamental win.

'jfb

--
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Re:Is there demand? by aurum42 · 2004-03-07 16:40 · Score: 4, Informative

I don't know what your development model is, but branching and tagging are often some of the most frequent (and slowest, in CVS) operations.
Many projects follow the "make branch, fix bug in branch, test branch and then merge" cycle, which makes a lot of sense.

--
"The slave who knows his master's will and does not get ready...will be be beaten with many blows."Luke 12:47-48
Re:Is there demand? by dietz · 2004-03-07 16:45 · Score: 5, Interesting

Before reading this, let the record show that I am a subversion fanboy. But I am only a Subversion fanboy because it solved almost all of my complaints about CVS. I am not involved with the project at all.

Do developers out there voice the need to store binaries?

Uh, most projects of any size will have at least a few binary files in their repository... icons, etc. But you could store those in CVS without too many problems.

Also, have there been many problems that required atomic commits? Can someone explain why this is important?

Rolling back changes without atomic commits is a pain in fucking ass. Have you ever had to do it? You have to track down every file that you changed (somehow... hopefully you can remember), check which version was the version prior to your commit, and get all those versions of files. For example "Okay, I need version 1.7 of foo.c and version 1.8 of barf.c and version 1.13 of foo.h." It's totally annoying.

Plus atomic commits just makes it much, much easier to keep track of what changes have gone it. This is my biggest, biggest complaint about CVS. File-level commits just make no sense. There is no time, ever, that I can think of when the ability to commit an entire changeset at once isn't better than committing a single file at a time.

Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...

Depends on your development process. During beta periods, it's common to make a tag or two per day, and if each tag takes ten minutes, well... it's not a big thing, but it's certainly annoying.

To me it sounds like a great product but I am not able to see a compelling reason why most development shops out there who are currently in CVS would rush to switch.

Certainly not every shop is going to "rush to switch". But, regardless, I imagine that every shop will switch eventually. It may take years, but subversion's advantages are significant enough that in my opinion it will become the new version control standard.

Also note that CVS was crufty and adding new features was almost impossible. Subversion targetted CVS features as their 1.0 milestone. But more importantly, the Subversion code base is a much better baseline to work from when adding new features. So you can expect that it will only get better in the future.
Re:Is there demand? by Endive4Ever · 2004-03-07 17:02 · Score: 5, Informative

Do developers out there voice the need to store binaries? I can imagine this being needed for web developers and such, but I think programmers can just build their binaries from CVS.

Yes, developers definitely need to store binaries. I worked on a project awhile back where the boot block code was a finished binary. Because CVS was used to house the project, a horrible kludge involving UUENCODE had to be used to store the binary commits. Sometimes the binary was created by a totally different tool that the main build machine doesn't have. In the case I speak of, the binary was built with an expensive licensed assembler for an Analog Devices DSP chip, and contained as a body of the 'build' because it was dynamically 'injected' into the dsp processor from the native processor, which happened to be an 80196.

There are always cases where a binary needs to be committed. Think about bitmaps and other resources. It doesn't make sense to 'generate them from source' every time a build is done.

Given all this, it's my understanding that with newer versions of CVS binaries can be committed safely. Is this even an instance where 'Subversion' is needed?

--
---
Re:Is there demand? by Anonymous Coward · 2004-03-07 17:29 · Score: 2, Informative

Do developers out there voice the need to store binaries?
It's a useful feature. Many companies like to store versions of binaries alongside sources. That way, if some customer has a bug with version 2.1.2.4 of Foofware, the company can just check that out, instead of figuring out (and hoping to get it right) how to build it.
And atomic commits are very useful. I wondere how CVS got so popular without them, but I think it is that people don't have them and didn't know what they were missing.
Subversion seems to be provide a lot more of the things I expect from SCM tools.
CVS seems to me to be a layer on top of RCCS. Now, I don't use either. I'm in a PhD program, and I use ClearCase LT thanks to the IBM scholar program. Sure, it's heavyweight, but I got used to it at HP and I like it. Feels solid.
Re:Is there demand? by Ninja+Programmer · 2004-03-07 22:54 · Score: 3, Interesting

Do developers out there voice the need to store binaries? I can imagine this being needed for web developers and such, but I think programmers can just build their binaries from CVS.
CVS lets you check in binaries. But it doesn't use any diff algorithm -- its just stores each instance. So its just inefficient. Any application that uses media will commonly have binary data.

The other thing is that Unicode source data is typically not stored in a purely ASCII compatible form. Moving forward, people are going to be using Unicode source data which at a low level can be considered essentially binary.

Also, have there been many problems that required atomic commits? Can someone explain why this is important?
Once you get to above about two dozen developers working on the same code base, you will end up with erroneous check-in collisions. Detecting and reversing out of these is a lot of fun.

I mean, the idea is you'll need to merge one way or another.
If you check-in mulitple files, then everything will be checked in except where there are conflicts. When you fix the "conflicts" you end up with an image that nobody actually tested. If you test it before checking in the fixes for the conflicts, then you leave the source tree exposed in a state where only part of your check in is there (and with enough developers there is an arbitrary number of partial checkins that the tree might be containing at any one time.)

These are all standard "race condition" problems. Commits have to be atomic for the same reason that transactions are atomic in databases, and mutexes/semaphores exist in operating systems.

IMHO, this issue alone is more important that all other combined.

Also, Subversions says that it is much faster at things like tagging, but tagging is not a very frequent operation...
Chicken and egg? If tagging were fast, wouldn't people be more likely to use it? Tagging is a way test people, release people, and even marketing people interact with the development results in a way that makes sense to them. Tagging is a very useful thing. Having numbered check-ins like Perforce makes this slightly less important, but why map your milestone ordinals to some homebrew scheme, when your source control can do it for you?
Re:Is there demand? by Jacek+Poplawski · 2004-03-07 23:22 · Score: 2, Interesting

CVS lets you check in binaries. But it doesn't use any diff algorithm -- its just stores each instance. So its just inefficient. Any application that uses media will commonly have binary data.

CVS stores binaries but it is not so trivial. When we put some binary data into our CVS tree we realized Windows users can't access it (need some setting in repository). CVS behaves differently in Linux and in Windows in this case.
Re:Is there demand? by spongman · 2004-03-07 23:28 · Score: 2, Interesting

Yeah, I love the fact that there's a revision number that's global to the whole repository.
We embed that number into each build of our product and our testers file bugs against a particular revision. If I can't repro a bug against my current code, I can just create a new branch at the given revision, compile, and I know I'm using exactly the same code that the tester was running.
Re:Is there demand? by 0x0d0a · 2004-03-08 02:16 · Score: 2, Interesting

That's because you checked in the binary in text format instead of binary, and the linefeed translation chewed up your binaries when switching between platforms.

This is particularly annoying with text-like formats, like Visual Studio 6's .dsw files -- they look like text files, they smell like text files, and CVS autodetects them as text files, but Visual Studio 6 throws a tantrum if you try to hand it a .dsw file with LF line endings.

--
May we never see th
Re:Is there demand? by 0x0d0a · 2004-03-08 02:22 · Score: 2, Informative

Rolling back changes without atomic commits is a pain in fucking ass. Have you ever had to do it? You have to track down every file that you changed (somehow... hopefully you can remember), check which version was the version prior to your commit, and get all those versions of files. For example "Okay, I need version 1.7 of foo.c and version 1.8 of barf.c and version 1.13 of foo.h." It's totally annoying.

Take a look at the -D flag. You'll be pleased.

I agree that CVS was almost mind-bogglingly crufty. It may be the single most crufty piece of software that I used regularly. Everything about CVS was defined by the way RCS worked, which just didn't make that much sense for a CVS-like environment.

--
May we never see th
Re:Is there demand? by Textbook+Error · 2004-03-08 04:09 · Score: 3, Interesting

if some customer has a bug with version 2.1.2.4 of Foofware, the company can just check that out, instead of figuring out (and hoping to get it right) how to build it

Your build system is seriously broken if this is the case. The whole point of revision control is that you can get back to a previous build just by fetching a specific tag or branch. If that means that you need to keep your entire dev environment (IDE+tools straight off the CD, headers, runtime libraries, etc) under revision control then that's what you should do.

Builds have to be deterministic if you want to have reliable QA, and making the build process reproducible is at least as important as using source control. The alternative is you end up checking out a build from 6 months ago that crashes, yet when you try and build the equivalent source the crash goes away. Having to say "um, this should be the same build but this one works and that one doesn't and I can't tell you why" is a sign that something pretty serious has gone wrong in your process.

There are plenty of other good reasons to keep binary data in a revision control system (images, sound, models, data for regression tests, materials for installers, etc) but trying to avoid having to have a deterministic build process shouldn't be one of them.

Third party libraries that you never build yourself can obviously be checked in as-is, but anything that you build from source should always be buildable from source on a brand new workspace. No ifs, no buts - if you can't produce a reliable build on demand, how do you know what's going into any of your builds?

--

Nae bother

Re:Summary? by Hamster+Of+Death · 2004-03-07 16:30 · Score: 2, Informative

See the project front page
Subversion

All your files are belong to us by wayne606 · 2004-03-07 16:50 · Score: 4, Interesting

It bothers me a bit that all the files are now in a big database. A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the ,v file by hand and extract the latest version. With a database, if things were to get corrupted enough (I have no evidence that this happens often, but still...) you are stuck. Just like with the windows registry, where if it gets messed up you lose big.

Any opinions on this?

Re:All your files are belong to us by Anonymous Coward · 2004-03-07 18:35 · Score: 2, Informative

Not only is it in a database, it's in a Berkeley DB. Some thoughts on this:

1) there is absolutely nothing about a version control system that requires a key/value database like berkeley DB. I think they just use it to get free locking and transactions. Strange.

2) berekeley DB is ultra-sensitive. Ever had to deal with a locked Berk DB, when no process was running that had it locked? You have to manually break the locks. Fun. This hasn't happened to me with subversion (yet), but I expect it to be a problem.

3) the *filesystem* already gives you atomic operations and so forth. They could've used that, and then written a thin compatibility layer for windows, which doesn't have posix filesystem semantics.

*grumble* *grumble* overengineering *grumble*
Re:All your files are belong to us by magnum3065 · 2004-03-07 18:49 · Score: 4, Informative

Someone else already mentioned the ability for live backups with Subversion. Another benefit of the database is built-in journaling support. BerkelyDB logs any changes before making them, so if your system crashes or something, the DB will be restored to a stable point. This is MORE reliable than what CVS offers, even with a journaling filesystem. Also I'm pretty sure that if you REALLY need to hack the DB, there are utilities that will let you do this. However, most of the scenarios that CVS admins needed to hack the ,v files for are no longer a problem in Subversion.
Re:All your files are belong to us by nthomas · 2004-03-07 19:05 · Score: 5, Insightful

It bothers me a bit that all the files are now in a big database.
When you used PostgreSQL, MySQL, or Oracle, does it bother you that your data is in a big database? Why do you worry so much about Subversion then?
A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the ,v file by hand and extract the latest version.
It is a good thing that you were able to hand-edit CVS repositories when they got corrupted -- because corrupt CVS repositories are a dime a dozen.
I've been using Subversion since January 2002 (yes, a full two years before 1.0 came out.) and I have never, ever, ever seen a corrupt repository or heard about one on the mailing lists. When someone did claim that they thought Subversion corrupted their repositories, the Subversion devs dropped everything to make sure this wasn't the case. AFAIK, it has never happened. (Usually it was the person using multiple servers to access their repo or putting their repo on a network share (Berkeley DB doesn't work over NFS/AFS/CIFS.))
Let me quote a Slasdot posting of mine from a couple of years ago:
...there is nothing that the dev team values more than the integrity of your data. Nothing. This means that once something has been comitted, it will never be lost.
My opinion has not changed in the past two years.
Thomas
Re:All your files are belong to us by Adrian · 2004-03-07 21:28 · Score: 2, Informative

With a database, if things were to get corrupted enough (I have no evidence that this happens often, but still...) you are stuck. Just like with the windows registry, where if it gets messed up you lose big.

I worry more about disk crashes and accidental deletions. This is what backups are for ;-)

You can also serialise everything into a fairly human readable file to with svnadmin dump and svnadmin load if you feel you need something non-binary.

Really not a problem as far as I'm concerned.
Re:All your files are belong to us by thelenm · 2004-03-08 08:09 · Score: 2, Informative

I'm not sure that being able to edit the ,v files by hand is an advantage of CVS. If anything, I see it as a disadvantage since: a) you're making changes "behind the system's back"; and b) it's easy to screw up.

The face that Subversion uses a Berkeley DB file backend doesn't mean you're hosed in case of problems, especially if you've been backing your data up. You can make a live backup anytime you want - with every commit, if you're paranoid. It's also possible to dump any or all commits to a human-readable format that can also be used to restore. But usually you won't even have to muck around with restoring from backup - if the repository gets wedged somehow, try 'svnadmin recover' and it will usually solve the problem.

There's a nice chapter in the Subversion online book that deals with all this stuff.

--
Use Ctrl-C instead of ESC in Vim!
Re:All your files are belong to us by ray-auch · 2004-03-08 08:14 · Score: 2, Interesting

Personally, all the data in Oracle, (SQL Server even) or PostgreSQL wouldn't bother me, MySQL might worry me a little, MS Jet / Access worries me a lot. BerkleyDB I'm not sure about, I know a little of its heritage on unix but would be a lot less sure on other platforms.

A lot of people's experience with source control and DBs will be coloured by Visual Source Safe and Jet (which it uses). It is ok until it gets corrupted, and then you are hosed. Keeping everything in readable files CVS-style is a BIG plus point once you've been in that situation.

I'm confused on your corruption statement - you seem to say both that it never happens, and that subversion never does it but other things ("Usually it was the person using multiple servers...") do. Which is it ? And if the latter, what recovery options are there ?

I am also wary of database-based products which are tied to one particular database - makes me worried there are low level hacks being relied on. I think a lot of people (well, me for one) would like to run _one_ rdbms on _one_ db-optimised server managed by _one_ dba - not a dozen different ones all over the place which all have to be managed differently (backup Oracle here, backup Exchange (yuk) here, backup MySQL here for appY, backup SQL here for AppX and now add another special here for source control...).

With stuff in one rdbms it is also easy to relate stuff together in queries (query source control operations related to versions in a trouble tickts app, for example).

If it supported multiple (at least two) rdbms from the outset configurable via odbc/jdbc/etc., preferrably also with an open schema and "just use sql like this to get file x version y from project z" - then it would give me (for one) far more confidence that it was worth looking into further.

PS. I haven't had sourcesafe (still have to use it for some stuff) corrupt a db in over the past two years either - the horror of seeing >5yrs of the whole team's code history suddenly inaccessible (shortly after tape drive problems...) stays fresh in your mind a lot longer.
Re:All your files are belong to us by empty · 2004-03-08 11:06 · Score: 4, Informative

...It is ok until it gets corrupted, and then you are hosed. Keeping everything in readable files CVS-style is a BIG plus point once you've been in that situation...
...I am also wary of database-based products which are tied to one particular database...

Subversion has a utility that might assuage your fears:
svnadmin dump
The dump command can do a (full or incremental) dump of your repository such that you can completely recreate its history. If you use this command for backup, you will be assured that you don't lose any data.

As a bonus, the dump file is human readable, so there should be no fear of losing data to an inscrutable binary file.

Some answers by magnum3065 · 2004-03-07 17:30 · Score: 5, Informative

Ok, I saw some questions about why people should switch from CVS to Subversion. The article does a nice job of covering what features Subversion adds, but people still seem to wonder why these are important.

Atomic Commits:
As stated in the article, if something goes wrong in the middle of a CVS commit (e.g. network goes down) it can leave the commit only partially complete. This can be a problem if changes in multiple files are dependent upon each other. Say I add a function to an API, then call it in other file. If the call gets committed and the API change doesn't, now the code in CVS won't compile. With atomic commits if the connection was dropped the commit would simply roll back. Then when my network came back up I could try to commit again, but the repository would never be left in a state where it didn't compile.

Constant Time Tagging/Branching:
In Subversion tagging and branching are fundamentally the same, they're both executed as a "copy" command. I'm not sure what the execution time is for these operations in CVS, though I believe it's linear to the size of the repository. In Subversion this is an O(1) operation. While one of the posts commented on tagging being an infrequent operation, this may be true, but why not let it be fast anyways? However, no matter how often you do tags, constant time branching is nice. I can at any time quickly create my own branch of a project to work from. Working in my own branch means that I can keep very granular track of my changes by committing frequently, without worrying about breaking something else. Once I'm satisfied with my changes I can merge my branch with the main code.

Storing Binaries:
"Binaries" does not necessarilly mean compiled code. There are plenty of things that can benefit from this. Anywhere you use graphics: web programming, GUI programming, or say game or other 3D programming andy you want to store your models. Or, you can store documentation in the repository: PDFs, Word docs, spreadsheets, etc.

Finally, the barrier to switching isn't all that high. The command line program has quite similar syntax, so switching is pretty easy, and the other interfaces such as the web viewer, TortoiseCVS, and IDE integrations generally have counterparts for Subversion.

Well, that's all I can think of for now. I'm actually going to try to get my company to switch over to Subversion from a commercial software they were using when we start on our new product. We're using a Java applet to interface with the repository now, and it's not very nice. CVS would work, since the main thing I want is integration with Eclipse and IntelliJ Idea, but there are plugins to support this with Subversion as well. However, Subversion has nice feature CVS doesn't, so I don't see any reason to use CVS over Subversion.

Live backups, baby by dFaust · 2004-03-07 17:33 · Score: 5, Insightful

This is a valid point, one that has crossed my mind in the past. But consider how many databases are out there in the world. Many with incomprehensible amounts of data. Given this, stability is obviously a number one priority to users and developers of databases, and certainly something that was considered before the Subversion folks a) chose to use a database backend and b) chose BerkeleyDB. Subversion has been self-hosted (they used Subversion for their source control) for over a year, and have yet to lose any data. While a year isn't that long, it's a start.

But using a database DOES provide advantages, as stated in the article. Mostly speed advantages, but also the ability to do live backups. If you try backing up an online (as in live) CVS server's files, there's nothing stopping people from doing commits, thus possibly botching your backup (you're no longer backing up the files you thought you were).

And when it comes down to it, backups are really where your safety lies. In the last CVS project I worked on, the repository was hosed twice. Once due to a careless admin, and once due to the hard drive dying. While we had some down time, virtually no work was lost, largely due to our nightly backups. The fact that CVS stored its data as plain text files certainly didn't protect us.

Re:Live backups, baby by halfnerd · 2004-03-07 22:18 · Score: 2, Informative

A year?

Taken from http://subversion.tigris.org/release-history.html:

Milestone 3 (30 August 2001): Subversion is now self-hosting.

there's over two years between that, and their 1.0.0 release, without *any* data loss.

Re:Windows server? by Eneff · 2004-03-07 17:48 · Score: 4, Insightful

How about individuals wanting source control on their at-home projects? I'm sure not going to spend the money on the MS control, but I don't have a *ix box up 24/7 either. (I use my laptop nearly exclusively, and my laptop hardware supports Windows better.)

Consider GCC by devphil · 2004-03-07 18:09 · Score: 5, Informative

Once a week, a snapshot release is made. That means a tag is added. This operation takes, on average, 40 minutes, because the GCC source tree is large.

Every time someome makes a branch, they create a tag just before branching (for use later on, with diffs and merging). 40 minutes to tag, another 40 minutes to branch.

All because these are, stupidly, O(n) operations instead of O(1). We'd like to move to Subversion, but can't, until they get annotate ('svn blame') fully working, because GCC developers spend a lot of time doing "revision-control archaeology".

--
You cannot apply a technological solution to a sociological problem. (Edwards' Law)

Re:Consider GCC by nthomas · 2004-03-07 19:16 · Score: 5, Informative

We'd like to move to Subversion, but can't, until they get annotate ('svn blame') fully working, because GCC developers spend a lot of time doing "revision-control archaeology".
Just curious, 'svn blame' was added 2003-10. What about it is not working for you?
Thomas
Re:Consider GCC by devphil · 2004-03-08 04:21 · Score: 2, Interesting

The person who tried it reported it wasn't working for certain branches off the main trunk. *shrug* Haven't tried it personally since the 1.0 release.

--
You cannot apply a technological solution to a sociological problem. (Edwards' Law)

Re:Windows server? by ogre57 · 2004-03-07 18:36 · Score: 2, Informative

In a Microsoft Shop developers will use Microsoft SourceSafe. period.

No, they won't. Can think of several shops/teams using PVCS, plus a handful on other products, but none using MSS. Up front (purchase) cost isn't much of an issue. Time cost (TCO) very much is. MSS is simply much too slow to be competitive.

I've tried both Subversion and Arch by dozer · 2004-03-07 20:14 · Score: 4, Informative

Subversion good points:

Finger feel is very similar to CVS
Flexible directory layout & tagging
Extremely stable development.

Subversion Bad Points:

Database & log files take up a LOT of space.
Quite hard to share repositories
No way to mark your branches (if you accidentally check out the directory containing your branches, you just got 50 gigs of 99.9% identical files...)
No distributed development
Pretty weak merging

Arch Good Points:

Extremely good distributed development
Super easy to share repositories
Pretty strong merging.
Very stable development

Arch Bad Points:

Forces you to give your projects weird names ("my-project--branch-1--1.1").
Forces each branch into a different top-level directory in your archive ("my-project--branch-2--1.1").
Doesn't feel anything like CVS.
Pretty slow (but they're working on it).
Somewhat difficult to resolve merge conflicts

I wish I could love Arch because distributed development absolutely rules. I could tolerate its bizarre command set, but I simply won't accept arbitrary (and ugly) constraints on what I name my projects and branches.

Verdict: I'm still using CVS. Subversion is very close to pleasing me enough to switch... I'll probably ditch CVS some time this year.

Re:I've tried both Subversion and Arch by natmsincome.com · 2004-03-07 21:54 · Score: 4, Informative

Some of your Bad points for Subvresion don't sound quite right:

*Quite hard to share repositories

The repositories can be read using any WebDAV complient software. If your talking about on the web the articles says you can use viewcvs as a web interface. If you want poeple to connect to the server then it should be setup by default as it's client server.

*No distributed development

If your talking about multiple servers like bitkeeper then I can't help you *I know nothing* but if your talking about client server then there's a misunderstanding as it's been designed to be client server.

I may have misunderstood what you were saying but the comments were a bit vague.
Re:I've tried both Subversion and Arch by dozer · 2004-03-07 23:22 · Score: 3, Informative

Quite hard to share repositories
The repositories can be read using any WebDAV complient software.
Ever tried setting up a WebDAV server? That fits anybody's definition of hard. The Subversion team recognize this, so they allow you to access the repository over ssh too (thank goodness!). Problem is, everyone using ssh must log in to the same user account or the permissions get screwed up. So, yes, it's quite hard to share repositories in Subversion.
No distributed development
If your talking about multiple servers like bitkeeper...
Um, yeah. OK, allow me to be slightly clearer: Subversion does not support decentralized development. Not at all. It's a major limitation.
Re:I've tried both Subversion and Arch by W2k · 2004-03-08 00:24 · Score: 2, Informative

Ever tried setting up a WebDAV server? That fits anybody's definition of hard.

I strongly disagree. Setting up a Subversion repository to be accessible over the 'net was PISS EASY, even for me, a first-time user. You can use the included light-weight server (svnserve) or Apache2 if you need options like complex authentication. It's very easy to set up and very nice to look at if you enable XML output. :)

There are howtos in the Subversion book. Happy reading.

--
Quality, performance, value; you get only two, and you don't always get to pick.
Re:I've tried both Subversion and Arch by Anonymous Coward · 2004-03-08 00:57 · Score: 3, Informative

Problem is, everyone using ssh must log in to the same user account or the permissions get screwed up. So, yes, it's quite hard to share repositories in Subversion.

i do believe that is wrong. using ssh for access the users need to be in the same group, and the repository directory needs to be sticky and writable to that group.

once setup correctly there is no problems with ssh access by multiple users.

Re:Windows server? by cyborch · 2004-03-07 20:55 · Score: 2, Informative

Also, and much more importantly: MSS only does file locking - not merging file content. It can hardly be called a "real" versioning system.

Binary files by ggeens · 2004-03-07 21:26 · Score: 4, Informative

Do developers out there voice the need to store binaries?

There are definitely reasons for storing binary (non-text) files in a version control system:

Images: quite obvious. You want to version all your artwork. For web-based projects, this can be a large part of your system.
External libraries: if you use third-party libraries, it makes sense to store them in the version control system. If you need a particular build, you check out the correct revision. This allows you to build the exact same binary as it was delivered before. (Of course, if you have the sources to the library, you might want to import them into your project. But if you don't change the sources, that might be overkill.)
Compiled files: some people like to store all object files into version control. Again, this allows you to retrieve a specific version faster (no need to recompile). Personally, I would do this only if the compilation takes too much time.
Documentation: whether you use MS Office or OpenOffice.org, documentation will be in a binary format. (OOo uses compressed XML.)
Test data: you might want to version your test cases, and those will consist of binary data.

--
WWTTD?

Re:Windows server? by Adrian · 2004-03-07 22:32 · Score: 3, Informative

In a Microsoft Shop developers will use Microsoft SourceSafe. period

Not in my experience. Some do and some don't. The absence of pain not using VSS can supply compensates for the lack of tool integration. Even MS doesn't use VSS internally ;-)

Subversion doesn't have a chance to compete because there is absolutely no way that it can integrate fully into the .Net development tools the way Microsoft's Own Source Storage Software is designed to do.

I think the people writing the Subway and sourcecross subversion-SCC interfaces might disagree with you there.

how do you migrate? by DeadSea · 2004-03-07 23:03 · Score: 2, Interesting

I can't switch unless we can convert our repository from cvs. Are there tools for doing this?

Re:how do you migrate? by TwistedSquare · 2004-03-08 01:20 · Score: 2, Informative

I asked this last time subversion appeared on slashdot, you can go see my comment and its helpful reply
Re:how do you migrate? by mgm · 2004-03-08 01:44 · Score: 5, Informative

Yep, Subversion comes with a conversion script, cvs2svn, which is under very active development right now. It's not quite so wonderful at converting CVS repositories with complicated branches, so you'll want to double-check the conversion, but lots of people are reporting success converting huge multi-gig repositories over to Subversion.
Re:how do you migrate? by Moonbird · 2004-03-08 01:44 · Score: 5, Informative

Look here...

--

--
All extremists should be taken out and shot.

Re:Windows server? by spongman · 2004-03-07 23:11 · Score: 4, Informative

I'm runing svnserve on a windows box in a production environment and it works great.

If you want to start svnserve as a windows service, google for srvany.exe, it allows you to run a regular win32 exe as a service.

Re:Windows server? by spongman · 2004-03-07 23:19 · Score: 2, Informative

i should add: I'd definitely recommend installing TortoiseSVN. Having the SVN operations available as a shell extension is a godsend. For example you can use SVN from within any FileOpen dialog. The only thing it's missing is a directory-diff, but on XP you can show the SVN status of files in explorer by configuring the attribute columns in the details view.

Also, I'd recommend downloading perforce's p4win 3-way merge tool. It's a little better than the one built into TortoiseSVN.

Re:database is a dependency by deKernel · 2004-03-08 00:22 · Score: 2, Insightful

You really need to explain the statement:

I suspect Subversion uses a database because it may be intended to run on operating systems with less powerful file systems.

A filesystem should not be used to hold multiple versions of a file as well as the meta-data associated with it. Less not forgeting the associations of multiple files that become a project. This is the work of a database, hence BerkleyDB. If you are concerned about "repairing" a file (aka db), there are command-line tools for just such an event, but you will probably find that you just won't ever need them. Just my 5000 sheckles.

It helps just a little by r6144 · 2004-03-08 00:46 · Score: 4, Interesting

I have used Subversion in quite a few (small, mostly one-man) research projects during the last six months. Before then I used RCS/CVS. Subversion does make me somewhat more comfortable, and I have little to complain about it, which means I probably won't ever look back.

However, IF there is no free software like Subversion, I'll rather do with CVS than using non-free stuff even if someone else pay the money for me. For example, CVS does not have atomic commits, so I use tags instead (ironic since CVS does tagging quite slowly, but still acceptable for one-man projects). Other weak points of CVS can also be worked around. It isn't pretty, but not THAT painful either. Actually, before I discovered RCS, I just did version control manually by saving a tarball after each day's work, which is tedious but still sufferable.

Of course, for large projects, version control is much more important.

Graph? by aled · 2004-03-08 02:17 · Score: 2, Interesting

Is there any client front end for subversion that makes a graphical tree of versions, like wincvs or cervisia? It's a very useful feature and I would like to have something equivalent for subversion.

--

"I think this line is mostly filler"

Any GUI Clients? by tjmsquared · 2004-03-08 02:49 · Score: 2, Interesting

Are there any GUI clients like wincvs for subversion yet? It looks like a much better tool, but I don't see my group switching unless there is a client that is at least as good as wincvs.

You want RapidSVN by Valdrax · 2004-03-08 07:48 · Score: 2, Informative

That's a pretty good question in my opinion, and TortoiseSVN's Windows shell-extension doesn't cut it. ("-1, Redundant" my ass.) If you're looking for something more like WinCVS, check out RapidSVN.

--
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").

Meta data and Moves by irontiki · 2004-03-08 09:04 · Score: 2, Interesting

I've been using CVS in professional development environments for about 5 years at several different employers. I love CVS but have been watching Subversion closely and with some anticipation.

The atomic commits will be nice but honestly the lack of them has never been a huge problem for my teams (atomic commits are probably less a problem with 6-8 people). The things that do bug me about CVS that Subversion is supposed to address :

1. the ability to move or rename a file w/o losing the history

2. the ability to set file permissions

3. ability to remove unused directories

I know that these things can be achieved by tweaking CVS's files manually but that's a long way from elegant. It's been a stumbling block when I'm trying to introduce a new team to CVS.

Slashdot Mirror

Ease Into Subversion From CVS

50 of 130 comments (clear)