Version control

  • Thread starter Thread starter Peter Morris
  • Start date Start date
Eeww! SourceSafe is the worst version control system I've ever used.
It's slow, painful, can lose data, has an appalling UI - it's basically
grim.

Now, it *may* have improved massively in 2005, but I somehow doubt it
:(
Click to expand...

Which is too bad. I did an evaluation of VSS when Microsoft first
acquired it back in 1995 (or so? can't recall for sure) and found it
entirely unsuitable for the needs of anyone who wanted source control.
Among its many problems, one of the worst was that the user was required
to ensure that they kept their current directory in VSS synchronized with
the disk directory; it was incredibly easy to accidently get extra copies
of your files in different directories.

I would've thought they'd have figured out how to fix all those problems
by now. Guess not. :(

Oh well...
 
Mark Rae said:
http://msdn2.microsoft.com/en-us/library/th1ac915(VS.80).aspx

See File Merge Improvements re the Copy-Modify-Merge workstyle - is this
what you mean...?
Click to expand...

It certainly sounds like they're embracing that more than they were.

It still sounds like it's an evolution rather than a revolution though.
(The idea that 4GB is enough data storage is incredible, for instance.)

For instance, I see nothing that suggests that branching is any better
than it was. This can be a real eye-opener in Subversion: branching is
basically instantaneous and *incredibly* cheap in terms of disk space.
You can switch from one branch to another and it just applies the
diffs; you can merge between different branches or difference revisions
in a branch, etc.

Has VSS finally become transactional (i.e. the whole commit works or
the whole commit fails)? I can't see anything about that, which is a
*real* shame - having a single version number which is automatically
incremented at every revision is like having a label automatically
applied to every commit, but a lot easier to deal with.

I'm slightly surprised that TFS isn't better than it is, given the
headway Subversion's made. Don't get me wrong - TFS is a *lot* better
than VSS, and has a lot of the above features - but it makes life hard
in unnecessary ways.
 
Mark Rae said:
Basically, 2005 is the first version which is really useable...
Click to expand...

That's an overstatement. I've used (and written about) VSS for years and
years. It may be the worst VCS out there, but it is useable.

I was so happy when I switched to Subversion, though!

///ark
 
It doesn't matter if VSS is transactional because VS.NET isn't (at
least 2005, maybe Orcas is better).

VS.NET commits files on a folder-by-folder basis. Subversion has
wonder support for atomic transactions and unique revision numbers for
each transaction, so we were really upset to lose this when accessing
svn through an scc implementation (pushok). Since switching to
VisualSVN integration (plugin so it does whatever it wants) we're
really happy to have full atomicity back.

Sam
 
Samuel R. Neff said:
It doesn't matter if VSS is transactional because VS.NET isn't (at
least 2005, maybe Orcas is better).
Click to expand...

Hmm... I use the SCC provider for TFS, and I'm pretty sure that works
transactionally as desired. I'll have to check it now though...
VS.NET commits files on a folder-by-folder basis. Subversion has
wonder support for atomic transactions and unique revision numbers for
each transaction, so we were really upset to lose this when accessing
svn through an scc implementation (pushok). Since switching to
VisualSVN integration (plugin so it does whatever it wants) we're
really happy to have full atomicity back.
Click to expand...

Ankh certainly works transactionally too. I tried VisualSVN a while ago
and I seem to remember there being very few reasons for or against
using it vs AnkhSvn, the most obvious one being that Ankh is free.
 
Ysgrifennodd Jon Skeet [C# MVP]:
Ankh certainly works transactionally too. I tried VisualSVN a while ago
and I seem to remember there being very few reasons for or against
using it vs AnkhSvn, the most obvious one being that Ankh is free.
Click to expand...

I can't speak for Ankh, because I've never used it, but VisualSVN is
much improved recently in respect of the steps needed to import a
project to svn. All you do now is to choose "Add project to Subversion"
(or something like that) from the VisualSVN menu - or the context menu -
and make sure you point to the right repository and the right folder and
it all just works really smoothly.


Peter
 
Mark Rae said:
Massively improved.
Click to expand...

But there still is no possibility of disconnected operation.

Subversion really wins from that perspective, with the ability to keep
working and find out what changed when you reconnect and commit. And, if
you need to commit disconnected, there's svk.
 
Just a point about marketing techniques.

Go to the VisualSVN site and product details are there, including the price.
It looks good.

Go to the PushOK site, and product details are there. Click the link to get
the price and it wants you to create an account with email and password etc.
I didn't bother.
 
yeah, I would agree that PushOK is not a very professional company.
However, until recently they were the only viable option for SVN
integration with VSS (ankhsvn sucked until a recent release that
improved many times over and visualsvn is very new).

Sam
 
Ankh certainly works transactionally too. I tried VisualSVN a while ago
and I seem to remember there being very few reasons for or against
using it vs AnkhSvn, the most obvious one being that Ankh is free.
Click to expand...

Both VisualSVN and AnkhSvn have had a number of recently releases and
improvements so it's comparisons that are even a few months old don't
really apply today. Nice to finally have some competition in this
particular area (vs.net / svn integration).

Sam
 
How go these products work with multiple projects/solution, eg I have static
libraries which are used in a number of projects.

VisualSVN didn't seem to want to know about it.
 
Ian Semmel said:
How go these products work with multiple projects/solution, eg I have static
libraries which are used in a number of projects.

VisualSVN didn't seem to want to know about it.
Click to expand...

It depends on how you organise things. Subversion can certainly work
with multiple projects etc - they're just files as far as it's
concerned.
 
How go these products work with multiple projects/solution, eg I have
static libraries which are used in a number of projects.

VisualSVN didn't seem to want to know about it.
Click to expand...

With Visual SourceSafe, you simply drag the library (or whatever) from one
project to another - this makes it available in both projects and, if you
change the library in one project, it updates it in the second...

I have a separate area in VSS which contains all my "shared" stuff, mainly
C# base classes and JavaScript includes, but also some aspx pages etc.

Whenever I create a new project, I simply drag the bits I need into it and
I'm good to go...
 
Don't really see the advantage of this. In SVN, all projects are available
to all other projects, as long as you have the required credentials. Unless
I'm very much mistaken, all you need to do is to add the "shared" stuff to
your solution. All your changes (to that project) will then get written
back to the Subversion in the normal way.



Peter
 
Don't really see the advantage of this.
Click to expand...

Really? The advantage is perfectly obvious, to me at least...

It allows you to have a collection of reusable objects (e.g. DAL,
encryption, Registry, mail, ADSI etc) which you can drop into new projects
as required and, if during the development of the new project you need to
enhance / improve one or more of the reusable objects, your enhacements /
improvements get automatically propagated into all your other projects which
also use those reusable objects...
In SVN, all projects are available to all other projects, as long as you
have the required credentials. Unless I'm very much mistaken, all you
need to do is to add the "shared" stuff to your solution. All your
changes (to that project) will then get written back to the Subversion in
the normal way.
Click to expand...

Er, well unless I'm missing something here, isn't that excatly the same
thing...???
 
Don't think so. You don't have to do anything in SVN to do this (except
checkout your shared project and add it to your solution). You mentioned
dragging and dropping things around in VSS. But maybe I misunderstood you.
My apologies if I did.


Peter
 
SVN has a concept of Externals where you define that some external SVN
"project" exists within another. On checkout it's copied so on the
user's local code exists inline.

Externals can be within a repository or across repositories (open
source projects for example).

We use externals for shared libraries and they're wonderful.

Sam
 
Back
Top