[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Plans for 1.5

From: eg <egoots_at_gmail.com>
Date: 2007-11-20 19:36:20 CET

Toby Thain wrote:
>> Just a suggestion, your MKS users may prefer an interface such as
>> SmartSVN rather than TortoiseSVN (we used to use MKS).
> Since you have made the same transition, can you comment further for the
> OP's benefit?

We also migrated from MKS Source Integrity to SVN.

We used MKS rcs and then Source Integrity since 1989 up until about 2
years ago when we started migrating to SVN

When you say Source Integrity you have to make a distinction between the
  Standard Edition and the Enterprise Edition.

The former is a file based rcs successor which added "projects" through
the notion of .pj files (which contained pointers to collections of
standard rcs files). This is the version that we used. It was a step up
from rcs but the project aspects were kind of broken in a lot of ways.
Every time you opened the mks program it had to scan the entire project
repository -- quite slow when you don't want it to be. I hated the
branch management too and they way diffs between branches and trunk show
up in an undesirable (to me at least) way. Merging tools were
rudimentary as well and were more limiting than SVN 1.4 is now.

MKS told me a couple of years ago that they were not planning on
developing new versions of the Standard Edition. We are a small company
so the Enterprise Edition made no sense. These were the last straws that
made us migrate away.

The enterprise version has bigger features (and cost) and they try to
compete against ClearCase as I understand it. We didn't use this version
so I cant really comment further.

Our windows users were very happy to use TortoiseSVN as it becomes a
part of the windows explorer view and it is very natural for them to adopt.

Once they get a handle on the basic tenets of going from the
Lock-Modify-Unlock approach to the copy-modify-merge approach it went
pretty smoothly.

Subversions documentation is excellent and we have never had a problem
that couldnt be answered on these lists.

Having said that, it is important to realize that we are a small group
of developers managing a substantially less complex repository / source
configuration compared to some of the bigger closed and open source
projects out there using SVN. So please factor that in when reviewing my

I hope this is helpful.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 20 19:38:10 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.