> From: allan juul [mailto:lambretta@inet.uni2.dk]
<snip>
> hmm, i'm in a similar situation. we currently have CVS and VSS
> and want to change both. we have two choices: Subversion or
> Visual Studio Team System 2005 (currently in Beta). the latter
> includes among other things a *quality* version control system
> that MicroSoft does indeed use themselves.
Allan, et al:
One of my old friends from high school, Buck Hodges, is on the Microsoft
team that is developing the new Visual Studio Team System. I
specifically asked him about some differences between Subversion and the
proposed Visual Studio Team System.
As I understand from reading MS public blogs, VSTS is used by the Visual
Studio team, but has no other significant use so far. The plan is to
build it so that it *can become* Microsoft's standard version control
system. Depending on how MS decides to license it, it could become
quite a formidable challenger to SVN on Windows. Early signs, however,
indicate that they're going to require a step *above* the MSDN Universal
subscription (??) in order to get VSTS. That means they probably
*won't* be "giving" it away like they did with VSS. (Long live
Subversion!)
For a functional comparison, I've copied below the Subversion Q/A
session I had with Buck Hodges. His comments start with [Buck]:
-------------------------------------------------
About Subversion (http://subversion.tigris.org), let me first tell you
the things we like about it.
1) The Copy-Modify-Merge model works so much better for us than the
lock-edit-release model.
[Buck] We agree. Hatteras default to allowing parallel changes.
2) Open-Source = Free (but for MS software, so does our MSDN Universal
Subscription...)
3) Programmable API means we can build our own tools around its engine.
Open-Source license allows us to install our tools wherever we need to
without having to pay royalties.
[Buck] We have an API, but I don't know whether there will be any
requirements that the machine have a licensed copy of a VS client on it.
Personally, I wouldn't think so, but I'm not involved in that.
4) Really cool integration with Windows Explorer
(http://tortoisesvn.tigris.org).
[Buck] Unfortunately, we won't have this in version 1.
5) True client-server-based network model, with web server (Apache) as
a PRIMARY server model (not an afterthought)
[Buck] I think we're the same on this.
6) Branching and tagging are constant cost (lightening-quick), rather
than being dependent on the number of files in the branch.
7) When changes are committed, they stay related in the repository so
we know what changes occurred "together" to accomplish a certain task.
[Buck] We use changesets, which appear to be equivalent to what you
describe. Checkin is also atomic - completely succeeds or completely
fails.
8) Ability to do "diffs" and "reverts" even when disconnected from the
network.
[Buck] We don't have this in version 1, though we have discussed similar
features.
9) Ability to have multiple working copies on the same branch. This is
helpful when you're working on two different features, or making "quick
fixes" at the same time as longer-duration feature updates.
[Buck] I'm not quite sure I understand this one. In Hatteras, each
branch shows up as its own tree. In other words, branching creates a
copy (though the content isn't copied in the DB), so you can have as
many branches on disk as you want.
10) WabDAV support allows repository access without installing dedicated
client. (Limited. Wished it was more fully functional, including
locking, but that's one of those "future" plans...)
[Buck] We don't have that in version 1.
And, some of the things we wished were in there...
1) SQL Server repository backend. Refactoring of the repository layer
to allow SQL-based "plugins" is a "near-future" planned feature, though.
2) Distributed repository replication. We have offices in Chicago and
Cleveland that often collaborate on the same projects. (not sure if
hosting repository on SQL server would allow MSSQL-replication to
address this problem)
[Buck] We've discussed solutions to this problem, but I don't know to
what extent we'll address the problem in version 1.
3) Ability to write our own repository layer. We have our own Document
Storage model - built on top of MSSQL/Oracle. We'd like to be able to
write a repository-layer plug-in to store the resources/deltas using our
own APIs, but still have the Version Control Engine handle all the "hard
stuff" like delta generation, revision history tracking, etc... (Future
"refactoring" of subversion repository layer might solve this for us)
[Buck] That's interesting. We won't support that in version 1.
4) Ability to write our own layer for the "working copy". Right now,
every Version Control solution we've seen assumes that developers do
their work on filesystem files in filesystem directories, and each file
on the filesystem maps to a single resource in version control. Well,
we'd like to use our own internal tools to manipulate a local document
database as our local working copy, instead of file system files only.
Similar to the custom repository layer, we would only implement the
interface that communicated between the Version Control engine and our
"Document Store"-based working copy, leaving the "hard stuff" to the
version control engine. There is some talk in the Subversion community
about refactoring the Working Copy layer, but it's a rather low priority
right now, and there are no specifics, either.
[Buck] That's interesting. We don't support that any better than they
do, but you could write code to mirror database on the file system,
pushing and pulling to keep them in sync. You could probably do that
with their stuff as well, so not much different. We have heard one or
two other requests for being able to version stored procs and other DB
items, and this is a generalization of that.
5) IIS-based server (in addition to Apache), including integrated
Windows Domain user identification and authentication.
[Buck] We use exactly that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 7 16:17:56 2005