General Question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am curious what others use for maintaining versions of projects.
Currently, I just save the builds in folders with a date on them. I do have
Visual Source Safe which came with .Net Enterprise however I currently have
not had the time to use it. What do others use or do?

Thanks
 
I am curious what others use for maintaining versions of projects.
Currently, I just save the builds in folders with a date on them. I
do have Visual Source Safe which came with .Net Enterprise however I
currently have not had the time to use it. What do others use or do?

Don't use SourceSafe until you're caught up on its shortcomings/dangers. I
use Vault from SourceGear:

http://www.sourcegear.com/vault/
 
Hi gabriel,
I use SourceSafe for quite long time and I haven't had any problems with it
so far

B\rgds
100
 
100 said:
I use SourceSafe for quite long time and I haven't had any problems
with it so far

I decided not to use VSS for several reasons:

- MS does not use it internally for anything

- MS recommends a periodic DB analyze for correct function
(http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnvss/html/vssbest.asp). If MS feels you should check the database
for corruption every _week_, then I am not interested!

- The data format for the storage data files is undocumented. If you
want to access the data because your VSS executables stopped working,
you're done for. If the data was corrupted and VSS cannot recover, then
you are done for as well, as you cannot try to recover by hand.

- VSS is _not_ a client/server application, so if a workstation takes a
crap while modifying the database, the DB could be corrupted for
everyone. If there is a network glitch, the same could happen as well.

So if VSS has worked for you, then it's a good thing. I just do not have
confidence in VSS reliability. I would really, really hate to loose my
source or any portion of it, and VSS is not necessarily confidence
inspiring in this aspect.

Vault, on the other hand, stores data in SQL Server or MSDE, both
documented and fully supported client/server databases (ie, the client
cannot ever force the server to corrupt data). Out of all the third
party version control products out there, I found no other that fully
supported all VS.NET projects (i.e., many products do not natively
support web apps) besides Vault.
 
100 said:
I use SourceSafe for quite long time and I haven't had any problems with it
so far

I've had many, many problems with SourceSafe, and wouldn't really
recommend it to anyone. It wasn't designed for use except on LANs, so
doesn't work particularly snappily over a VPN, its GUI has some
horrible issues (fixed sized dialog boxes, poor use of threads) but the
main problem is that the database can easily get corrupted, which is
inexcusable for something which is meant to protect your data.

Personally I haven't seen anything as nice as the Eclipse interface to
CVS, but there we go... (There are various design shortcomings with CVS
too, particularly with regard to renaming/deleting files, and there are
other projects such as Subversion which attempt to fix them.)
 
I decided not to use VSS for several reasons:

- MS does not use it internally for anything

- MS recommends a periodic DB analyze for correct function
(http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnvss/html/vssbest.asp). If MS feels you should check the database
for corruption every _week_, then I am not interested!

I have had Source Safe databases for years with up to 30 people
accessing and no corruption, only running analyze about once a year
MS are being very conservative with once a week
- The data format for the storage data files is undocumented. If you
want to access the data because your VSS executables stopped working,
you're done for. If the data was corrupted and VSS cannot recover, then
you are done for as well, as you cannot try to recover by hand.

If the VSS exes stop running you can use it accross a LAN
You can recover the most recent version of files from the data
although it would be time consuming if there are a lot of files
And you should be running backups to protect against corruption anyway
- VSS is _not_ a client/server application, so if a workstation takes a
crap while modifying the database, the DB could be corrupted for
everyone. If there is a network glitch, the same could happen as well.

This has advantages as well as disadvantages
the main advantage is simplicity.
You can backup by simply copying the data folder
It requires almost no setup, training or administration
Vault, on the other hand, stores data in SQL Server or MSDE, both
documented and fully supported client/server databases (ie, the client
cannot ever force the server to corrupt data).

doesn't mean the data can never get corrupt so you still need backups
and these are undoubtedly more complex since there will be locking
issues

I have used VSS for about 5 years, both personal and in work.
I have only twice seen problems with corruption in that time, those
problems may have been partly caused by the fact that the DB was about
4 or 5 years old and alalyse had never been run on it.
The problems were easy to fix

By comparison to products like Clear Case which require a great deal
of scripting and administrationa and have other disadvantages I'd go
with VSS.
Never used Vault so it may be better but why pay when you don't need
to.

Vin
 
Vincent Finn said:
I have had Source Safe databases for years with up to 30 people
accessing and no corruption, only running analyze about once a year
MS are being very conservative with once a week

Then I suggest you're lucky. The most common problem we've had is
Version Not Found on some files when fetching a label. Do you have much
in the way of labelling/branching/sharing/merging? I suspect that's
where the problems come.
If the VSS exes stop running you can use it accross a LAN
You can recover the most recent version of files from the data
although it would be time consuming if there are a lot of files
And you should be running backups to protect against corruption anyway

It's far from easy to spot the corruption immediately, unfortunately.
Being able to get the most recent version of the file just isn't good
enough.
This has advantages as well as disadvantages
the main advantage is simplicity.
You can backup by simply copying the data folder
It requires almost no setup, training or administration

On the contrary, to make sure people don't muck things up it very
*definitely* requires training, as do all resource control systems, I
suspect.

Something like CVS can be incredibly easy to set up as well - literally
just run the installation program, answer a couple of questions with
defaults, and you can be done: a simple proper client/server system. I
believe the data in a CVS system can also just be copied.
doesn't mean the data can never get corrupt so you still need backups
and these are undoubtedly more complex since there will be locking
issues

Sure - but there's a considerably greater drive for MS to make sure
that SQL Server databases don't get corrupted than for them to do the
same with VSS...
I have used VSS for about 5 years, both personal and in work.
I have only twice seen problems with corruption in that time, those
problems may have been partly caused by the fact that the DB was about
4 or 5 years old and alalyse had never been run on it.
The problems were easy to fix

Then again, I believe you're lucky, or happen not to have been using
the operations which other people *need* to use but which can cause
corruption.

Are you suggesting that people are making up the horror stories about
VSS, or that they're doing really stupid things? If it's the latter,
should it even be possible to do things which are sufficiently stupid
as to corrupt the database, just from the admin/user tools?
By comparison to products like Clear Case which require a great deal
of scripting and administrationa and have other disadvantages I'd go
with VSS.
Never used Vault so it may be better but why pay when you don't need
to.

Exactly - use CVS (or another free but well-supported system)
instead...
 
Vincent said:
doesn't mean the data can never get corrupt so you still need backups
and these are undoubtedly more complex since there will be locking
issues

I guess you don't do much DB administration. Locking issues (of which we
have none) are a walk in the park compared to going through data
corruption of the most expensive kind: Source code corruption.
I have used VSS for about 5 years, both personal and in work.
I have only twice seen problems with corruption in that time, those
problems may have been partly caused by the fact that the DB was about
4 or 5 years old and alalyse had never been run on it.
The problems were easy to fix

I'll put it this way: We have been running pretty big client/server
databases, mostly Oracle, and have _never_ seen a data corruption
problem.

Where would you rather have your source code?
Never used Vault so it may be better but why pay when you don't need
to.

First of all, VSS is _not_ a free product, so don;t give the impression
that MS gives it away. A VSS license does get included in many of MS
development products, but you still need a valid license from MS to run
it.

Second of all, Vault costs $1000 for 5 users including the SQL Server
licenses. MUCH less than a single event of minor source code data
corruption (rebuild what you can, re-implement what you cannot recover,
debug the whole thing).

Honestly, my time is worth much more than the cost of a versioning
system...
 
Then I suggest you're lucky. The most common problem we've had is
Version Not Found on some files when fetching a label. Do you have much
in the way of labelling/branching/sharing/merging? I suspect that's
where the problems come.

merging in VSS is very poor so rarely used it
the others were used a lot
Then again, I believe you're lucky, or happen not to have been using
the operations which other people *need* to use but which can cause
corruption.

Are you suggesting that people are making up the horror stories about
VSS, or that they're doing really stupid things? If it's the latter,
should it even be possible to do things which are sufficiently stupid
as to corrupt the database, just from the admin/user tools?

I'm not suggesting either.
The few incidences of corruption I saw were caused by bad luck,
windows or network problems exactly at checkin time or some such.

The one point I would make is that the companies I have worked in have
rarely needed to use the older versions in anger which might explain
the lack of problems.
Exactly - use CVS (or another free but well-supported system)
instead...

I use VSS at home because it come with Visual Studio

If I was setting it up in a work situation I would opt for CVS too
but my main point is that VSS can safely be used

There are horror stories and there can be problems but for small
volume simplistic use it is a simple zero maintenance solution

If you have stricter requirements then you will need something better
but not everyone needs a heavy duty system

Vin
 
I guess you don't do much DB administration. Locking issues (of which we
have none) are a walk in the park compared to going through data
corruption of the most expensive kind: Source code corruption.

Thankfully no :-)
I'll put it this way: We have been running pretty big client/server
databases, mostly Oracle, and have _never_ seen a data corruption
problem.

Where would you rather have your source code?

Depends whether I could afford the resouses to run the big database.
I have mostly worked in small companies where there are no free people
for administration.
So the zero-admin method is the better option
First of all, VSS is _not_ a free product, so don;t give the impression
that MS gives it away. A VSS license does get included in many of MS
development products, but you still need a valid license from MS to run
it.

It comes bundled with VS. I certainly would pay for it
Second of all, Vault costs $1000 for 5 users including the SQL Server
licenses. MUCH less than a single event of minor source code data
corruption (rebuild what you can, re-implement what you cannot recover,
debug the whole thing).

your defintion of minor is not the same as mine
The instances of corruption I saw in VSS could be fixed without
reimplementing anything

Oh well, I amn't an MS salesperson so I amn't saying VSS is perfect or
suits everyone merely that I have used it in work and at home and have
had minimal problems.
By comparison to Clear Case (the main alternative that was recommended
at the time) time fixing corruption was way less than time required in
setup and maintainence

Vin
 
Vincent Finn said:
merging in VSS is very poor so rarely used it
the others were used a lot

Then I maintain you were mostly lucky :)

(We gave up on merging a while ago as well...)
I'm not suggesting either.
The few incidences of corruption I saw were caused by bad luck,
windows or network problems exactly at checkin time or some such.

Network problems exactly at check in time should *not* cause a corrupt
database though. I'd be quite happy to accept that that might well be
the cause of the problems, but that just makes it a shoddy product IMO.
Something which is meant to keep your resources safe should *not*
assume that the network will definitely be up during a whole check in
(which can take a while sometimes).
The one point I would make is that the companies I have worked in have
rarely needed to use the older versions in anger which might explain
the lack of problems.

By "older versions" do you mean "older versions of VSS" or "older
versions of the code"?

Note that I've seen the Version Not Found problem on code which has
*just* been striped.
I use VSS at home because it come with Visual Studio

If I was setting it up in a work situation I would opt for CVS too
but my main point is that VSS can safely be used

VSS might perhaps be safely used if you're absolutely sure that you
won't run into "bad luck" or network problems. Do you really want to
trust your code to luck though?
There are horror stories and there can be problems but for small
volume simplistic use it is a simple zero maintenance solution

If you have stricter requirements then you will need something better
but not everyone needs a heavy duty system

I don't think "not trashing my code" really counts as a strict
requirement, does it?
 
By "older versions" do you mean "older versions of VSS" or "older
versions of the code"?

older versions of code
would dif and get histories on files but rarely had to get old
projects and use them
Note that I've seen the Version Not Found problem on code which has
*just* been striped.
eek

VSS might perhaps be safely used if you're absolutely sure that you
won't run into "bad luck" or network problems. Do you really want to
trust your code to luck though?

at home yeah
no branching, no network, for a single isolated PC not much can go
wrong
I don't think "not trashing my code" really counts as a strict
requirement, does it?

you have had much worse experiences than I have
it has never trashed my code (the problems I encountered involved it
trashing someone elses code so not so serious :-)

Vin
 
Back
Top