On Mon, Jun 8, 2009 at 4:49 AM, Marko Käning <mk362_at_mch.osram.de> wrote:
> what are your users running as an operating system? in this situation, it
> sounds like a true dcvs would excel. and actually, if your users arent on
> windows, id wholeheartedly recommend git-svn.
>
> I'd also recommend to go for a real distributed VCS!
Sooner or later, even distributed repositories have to send information back
over the network back to the original repository. And, if there are network
issues, then you'll have the same issues all over again.
ClearCase is the only true version control system that has multiisite
capabilities. Then again, if you ever used ClearCase multisite, you know why
no one else bothered. By having multiple repositories in multiple locations,
you end up with a problem of who really owns what. Plus, trying to keep
everything in sync, and the extra configuration headaches. ClearCase
MultiSite was a godsend back in the days when most remote operations took
place over a line whose speed was measured in kilobits, or when it was
impossible to even allow remote access to a repository, but it's more of a
pain in this day and age.
There are some real problems with distributed repository systems that most
people tend to brush off. They feel if Git is good enough for Linux, it's
good enough for them, but they don't understand the issues that Git is
trying to solve:
The big issue for Linux is how do you let tens of thousands of people make
contributions without having to maintain tens of thousands of developers in
a database. A distributed repository handles this well. I could checkout
from Linus Tolvard's version of the Linux repository, make my changes, but I
doubt Linus will accept them.
Instead, what I need to do is find someone down the line who is working on
Linux and knows me. That person will give me access to their copy of the
repository. They'll accept my changes, and then submit them to their
trustee. That trustee will submit them down the line until the changes are
filtered to Linus who decides exactly what will and won't go into Linux.
Even with a distributed repository, sooner or later, you have to get the
changes from the field back to the main repository, and if the network is
slow, getting those changes back and forth will be slow. You could simply
delay getting those changes from your remote locations, and only synchronize
your repositories on a weekly basis, but then you run the risk of having
merge problems.
The big question is to figure out exactly what is slowing things down. Is it
your Subversion repository? Is it your network? Is it the VPN? Or, maybe it
is Subversion itself...
On a checkout, not only does Subversion copy each and every file over the
network, but it also makes a "base" duplicate on your drive. Subversion was
designed to work comfortably in a disconnected mode. Except for "checkout",
"update", and "commit", most developers can easily do their work without
being connected to their repository. You don't need to tell the repository
that you are editing a particular file. You don't need to tell the
repository you want to see what changes you've made.
The problem is that virus protection software can slow things down to a
crawl. Imagine an antivirus software that scans each file created for a
virus. If I checkout a dozen files, I'm not just scanning those files, but
the dozen "bases" too, and the property files and the property bases inside
the .svn directories. If your VPN is scanning for viruses too, you'll find
each packet in Subversion is being sniffed and that will slow things down
too.
You could try Perforce which is a commerical software that's $800 per
license. Perforce has several tricks that make it a bit faster than
Subversion. It doesn't create .svn or CVS directories to track files which
makes it a bit faster on checkouts. It also has "proxy" repositories that
allow you to put a copy of the repository in a remote location, and the
proxy and main repository get sync'd in the background. I've found this
great for this type of situation.
But be warned: Perforce has a few quirks: It is not easy to work
disconnected to the server. (You can, but it involves a few tricks to work
off line and you have to synchronize your working copy to the server once
you reattach.). Perforce setup can be quite picky. (Perforce practically
insists that server storage must be completely local to the server.
Something many shops can't do). Plus, you have to maintain a license file
and pay $800 per user. Have a dozen or so developers, and you're talking
about tens of thousands of dollars.
So, do some testing. Find out how long it takes to send a file back and
forth over your network. If your network is slow, distributed repositories
won't necessarily make things any better. You'll have to find out what is
slowing down the network. If it's your VPN, you might want to try a third
party source repository like SourceForge or GForge which both use Subversion
as their revision control system. If it is the antivirus system that's
slowing Subversion down, try configuring your antivirus system not to scan
your Subversion working directory. Most people find this almost doubles
Subversion's speed.
Like with any development issue, you have to know what the cause is before
you can get a cure.
On Mon, Jun 8, 2009 at 4:49 AM, Marko Käning <mk362_at_mch.osram.de> wrote:
> > what are your users running as an operating system? in this situation,
> it
> > sounds like a true dcvs would excel. and actually, if your users arent
> on
> > windows, id wholeheartedly recommend git-svn.
>
> I'd also recommend to go for a real distributed VCS!
>
> I just learnt on SVK's (another DVCS) mailing list that git is actually
> even under windows now easy to use with msysGit
> (http://code.google.com/p/msysgit/)!
>
> Perhaps mercurial (www.selenic.com/mercurial) might be another alternative
> for you!
>
> Greets,
> Marko
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360239
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360312
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-08 17:05:20 CEST