Re: Subversion and TortoiseSVN

When I was using ClearCase it was admitedly with a *much* larger team than I am working with now, so I guess it's not a totally fair comparison. However, this team is likely to be never greater than 5ish in number.

I too am using the native filesystem, I didn't consider the database option because all the warnings put me off! I am using a server but I am not using Apache, I am using the simpler svnserve, seems to run fine, although I've not given it too much exercise yet...

So you have your repositories on network shared drives, and just use the clients to access them directly? This would be simpler for us, although I am currently using the server to do it. Is there any drawback to doing it your way? One of the criticisms of VSS was that it accessed the database directly so if any client misbehaves it can corrupt the database, however I figure that SVN is atomic with it's commits so perhaps this isn't an issue? Also, I think the client PCs are probably better maintained than the server, since it has no "owner" to tend for it's needs!

I don't need a web browser to view the repository, the repo-browser tool does me fine.

Hotcopy, not heard of that, name suggests what it's for though. I will look into that...

Regards, Richard.

Be 100% confident. VSS is garbage.

I have worked with teams of 15-20 developers using Subversion with perfect ease. We also use some "glue" utilities providing web browsing (WebSVN), RSS from Svn logs

automatic annotation of Bugzilla issues in commit messages announcement of commits in Jabber room and other fun stuff. Svk is another technology that can help bring larger groups together although I don't have personal experience with it yet.

I have not seen any slowdown proportional to size of repo (up to

7-10GB, 7000 revisions). I don't believe there is such an effect at least when using the FSFS repo format.

Sounds like you've had a good experience then... thanks for the input. I'll look at those utilities if the tool gets taken on.

Cheers, R.

Most users don't report significant slowdowns as the repository grows. Perhaps it's the file-system access you're using, instead of the server?

Almost nobody uses the file:/// option (which is what you're using if you're not using either of the server options). One Real Good Argument in favor of a server option (either the simpler svnserve or the more-flexible server using apache) is that you don't have to mount the repository drive on every user's machine (which is generally a security no-no). When using the file:/// access, each user has to have permission to write to the server files and it's easy to screw things up. Using svnserve or apache, only one "user" (usually svnowner) has write access to the repository. In other words, users interact with the server and only the server is allowed to actually update the repository.

Also, the server mechanisms allow the admin person to set up permissions regarding what users are allowed to commit changes to the repo and who's allowed to only view it.

-a

See my reply to VxWorksNovice's post. Basically, you want the repository to live on a drive connected directly to the server, and clients interact with the repository through the server and never directly as with file:///.

Atomic commits means that if any part of the commit fails for whatever reason, then the entire commit is rejected. This is true for all repository access mechanisms (file:/// or server). And, yeah, it makes fouling up your repository a bit more difficult. :)

A "server" machine can be anything. At work, I run the "server" on my desktop/devel machine. The machine (an XP box) runs svnserve as a service using SVNService. At home, I have a Mac mini (running OS X

10.4) running svnserve from launchd; the repo lives on an attached FireWire disk. The advantage of a Unix-type machine is that I can ssh to it (and in fact you can access svnserve through an ssh tunnel and take advantage of ssh's authorization mechanisms) and run a cron job for backups and all of the good stuff Unix provides. And yes, you can run the server on a Unix box and have Windows clients.

I always access the repo through the proper svn://mymachine/project/ mechanism instead of file:///. I've installed both the command-line tools (both the server and client programs are included in the package) and TortoiseSVN on any machine I'll use to access the repo. So, no matter where I am on the network, I never worry about whether a drive is mounted on the machine or any of that. It just works.

$ svnadmin hotcopy is the command used to make a copy of a live repository. There's also a python script one can use as part of a cron job to automate repository backups. Again, a reason for a Unix box for your server, as you need to be logged onto the server to run svnadmin commands, and that's easy with ssh or telnet or whatever.

-a

According to the subversion website, the database backend can be faster at finding the latest version of the repository when you have very large numbers of versions saved - I think this is a minor issue. Other than that, if you have a large repository, you will get a large number of files in each directory. Different file systems are better or worse in such cases. For example, FAT32 can get very slow when you have lots of files in a directory (it's not ordered, so the search is linear), as can ext2 on linux, while NTFS is better and reiserfs is virtually unaffected by the number of files in the directory.

Agreed - while your svn client software might not corrupt the database accessible as a file share, other software (or the user) on the client PC could do so accidentally. It's fine for a small (single machine) svn setup, but for anything more, it is best to coordinate through an svn server.

As it happens, in our system (the setup of which has been in place long before I started at this company) the network drive on which the repository will be placed is available to (and mounted by) all users but only read-only. Only our software group and a few higher level bods have write access to the folders where the repositories will be placed. So in effect, the security is the same? The users that have write access to the folders (were I using the file:// option) will be the same users that will be allowed to modify the files via the server anyway.

I would prefer the system you suggest where only the server has write permission. At the moment though the machine has not been set up specifically as a server, it has just become one because nobody was using it and I started installing server-type software on it :-/

R.

This is a good point. I think this is reason enough to pursue a server solution!

(Which I already have, although I wasn't sure about it's need)

R.

I guess having a drive connected directly (you mean locally within the machine?) means faster performance? The problem is, all the networked drives are backed up by our IT dept, the server in our little software engineering group isn't (yet). As mentioned in another post, it's not a true server really, it's just a normal machine that has gradually been hijacked for server use! (In case I'd not mentioned it, I use a server on a dedicated machine, but the repository is stored elsewhere on a networked drive)

I guess another advatange of using the server option is you can move the repo without needing to tell clients...

R.

No, it's not the same!

When using file:///, any user who has write permission can accidently wipe out the repository. A simple rm would do it, or, for Windows folk, clicking on the directory and deleting or renaming something within, or pick your favorite OOPS.

A proper server setup includes a user (in my case, called svnowner) under which the server daemon runs. That user is the only user who has write access to the repository. Anyone who wishes to access the repository needs to be authorized to do so, but this really only controls whether and how the server will respond to user requests. The users interact only with the server daemon, and the server daemon is the only thing that talks directly to the repository database, because the server daemon is running as the only user with write access to the repo

Got it?

-a.

I think I'm with you.

Basically while the access rights are "write" in both instances, the server daemon isn't likely to *accidentally* wipe out the repository, unlike a user with file:// access?

R.

Yes, it all depends how much you care about your data. If you care *a lot*, you'll set up a server, likely with ECC, mirrored disks, properly configured permissions, a serious O/S, suitable access method (I use http[s]) and a regular backup schedule (e.g. a cron job to verify and 'svnadmin dump' your repositories to another place).