Verkerk, Onno wrote:
> I'm currently investigating on some candidate version control systems for
> deployment in our company, and Subversion is included in the list.
Nice to know it is on the short list of top tools to use.
> I already did some testing on svn and found it pretty easy to use. I
> tested the combination Subversion+TortoiseSVN connected to
> Subversion/Apache2. Everything seems to be there and readily
> available.
I take it by this that you will be primarily using this in a MS
environment?
The worst problem I have heard of so far is that on slow filesystems
the organization of many small files can cause slower performance by
comparison to operation on faster filesystems. MS notably has a slow
filesystem and so there have been complaints of performance problems
there. The functionality is very good though and personally I run on
a slow filesystem (HP-UX) and I accept one to get the benefits of the
other. On a fast filesystem it is awesome!
> But of course, testing is on small repos, not on the real-life big
> ones.
Subversion is used on many other large projects. I doubt you will
find anything truly interesting there. It is solid.
> I found out that many people complain about Subversion's branching/tagging
> mechanism. For one thing, this seems to become the most dominant issue about
> Subversion.
Tools like RCS and CVS have been around for a long time. People
accept that they work as they work and that is just the way that it is
going to be now and into the future. They don't really support many
of the newer types of global development being done today. But
subversion being an active project people want it to be better than
previous tools. Therefore the most obvious thing to look at is how to
do active development on a global scale. This is clearly on the
roadmap for subversion development. It just keeps getting better and
better.
But to be fair subversion does not have distributed development built
in as a core feature. That is because CVS did not either. That was
not the design goal. Instead the design goal was to keep the CVS
model but significantly improve it. Subversion is a better CVS. If
you would not consider CVS at all in the past due to the feature set
of CVS then you might not be happy with Subversion today either. That
is okay. Subversion is not for everyone. But if you were a previous
user of CVS then moving to Subversion is a step up in capabilities and
performance in almost every feature.
> I compared it with other tools (BitKeeper, Perforce, ClearCase,
> Surround SCM) and they claim to do a better job.
First it is amazing that you are comparing those tools to each other.
One of those tools is clearly different from the rest. Which ones are
closed source proprietary commercial products and which ones are open
source free software projects? RCS, CVS, Subversion, others not
mentioned, are free today and will always be free in the future. You
will never lose your license to operate on the data. You will never
be prevented from using it at the whim of the company offering it.
That is a huge benefit just by itself in terms of data security. But
if that is not seen as a benefit to you then that is okay too.
Choices are being offered and differnet needs will make different
choices.
> Here are some references that discourage the use of Subversion:
> http://www.bitkeeper.com/Comparisons.Subversion.html
Be very careful of marketing from the commercial organizations. They
make their money selling their product. They don't make any money if
they don't sell their product over all others. As I read that
marketing I had to choke back several outbursts of denial about
several of the bullet points there. But they are carefully crafted to
elicit such a response. If that were posted to a news group it would
be called "a troll".
GNU Arch, Monotone, Bazaar, others are designed as a distributed
version control system. Their paradigm is different. Technically
these can be much more flexible than a centralized system. They have
a lot of advantages. But they are also much harder for the user to
understand and grip upon mentally. I am going to be teaching them how
to use this new system and that affected my choice. Having the
distributed VCSs as a choice for my team I pushed for Subversion over
them because of the ease of use and administration aspects. Svn is
not perfect. But it does the 95% case of what we need very well. It
is quite easy to get someone up to speed using it. My needs at work
are not the same as the Linux kernel. Different needs mean different
choices. What are your needs? You will need to understand that and
make your own choices.
> http://www.maynidea.com/topics/subversionstinks.html
That just seems like a "rant" that is typical of the unhappy person.
There are as many rants bashing reserved-lock systems as there are
bashing copy-modify-merge systems. Really you just need to ask
yourself which model you prefer. Then by all means select a system
that supports what *you* want to do.
Note that subversion 1.2 has reserved-locks. It is a new feature just
introduced to subversion. So much of the previous documentation will
refer to the previous capability list which does not have locking.
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
> http://www.pushok.com/soft_svn_vscvs.php?PHPSESSID=392eaa27da6675121041fa261
> c30fa49
They don't like the current tagging and branching model. There have
been complaints about it. See the list for lots of discussion.
Everyone agrees that subversion operates differently. They do not
like how it works. Others do. The important question for you is do
you think it works okay for you to use or not?
They rant about other things that I completely disagree with. They
really seem to like the cvs edit feature. I find that to be
completely useless. There are other points that I could debate with
but why? Actually that was a much more balanced rant than most. If
they want to use CVS that is fine.
> They all complain about missing features that are already fixed, but
> branching remains an issue.
Branching is certainly functional. It just has some warts that make
it less pleasant to use in some cases than others. I understand the
warts. They are not really *that* bad. I usually have to keep track
of the versions from which I am branching and merging. It would be
nicer if svn tracked merges. But that does not make it impractical.
It would be better if you tried a few of the cases discussed in the
book. Then you could come back and discuss the specific details of
the operations. What in particular is or is not working for you.
> I also received a confidential note from Seapine (Surround SCM) in
> which branching in Subversion is said to be a disaster.
Ahem, you may not have noticed but this is a public list. If that was
really confidential then you just violated your agreement with them.
Branching in subversion is quite good and is certainly not a
disaster. There are a number of better but harder to implement ways
of doing branching. Improving things is under heavy discussion.
Things are quite a bit better than in CVS.
> But I like Subversion! Anyone there with a good opinion on how to
> successfully use branching in a team with some 15 developers on the same
> code base?
That question does not have an answer. Because the obvious answer is
just use subversion and branch normally. Don't do anything crazy.
Just do normal things. Read the documentation. Use the tool in the
documented manor. Please don't take this harshly but you have to have
something more specific in mind or there is no way to respond to this.
What version control system have you been using previously at your
company? I would be willing to bet that subversion is already at
least as functional as what you have been using and likely more so.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 5 01:05:36 2005