Sorry I'm so slow to respond to all of this. I've been very busy, and
have not taken the time to keep track on this thread (or the mailing
list in general). As for some general responses to some of the various
"posts":
It is very useful to convert our old VSS database over. I suppose if a
person (or team) never (or rarely) needs to refer back to old revisions,
then this wouldn't be as big a deal. As it is, we are checking changes
and comments quite frequently, as our product is fairly large and we
have a decent number of people working on it (which means we need to do
a more detailed analysis of how "safe" it may be to change a particular
section of code by finding out why the code was written the way it was,
as comments in code rarely paint the full picture). We also (of course)
use it to our advantage in tracking down problems, which may require you
to scan back through a file to figure out when a particular section of
code changed, what the changes were, and why. This would be difficult
at best if we had to constantly use two different SCM systems. We're
keeping our VSS repository for other reasons, such as insurance for old
versions, but we want to never have to use it, if possible.
As for the "wedging" of the db, I am fairly confident that I made the
right decision when switching to FSFS. I'm pretty methodical when I do
things, and thus when I started having troubles with Subversion (as with
most things I do) I assumed that it was working and that I was doing
something wrong. So I made sure I had the latest version of BDB, as
well as the latest version of Subversion. This is running on a brand
new Dell server with Apache2 as the conduit. It is running a very
recent version of RedHat (though the exact distro eludes me at the
moment, and I'm too lazy to check it). So, after going through this
process and updating BDB and Subversion and re-setting up the
environment, I went back to converting, only to have the same issues I
had prior to doing this exercise. I posted to this list, and was
queried for "configuration" info, which I provided, only to have no
responses to my questions. At that time I went into a holding pattern
for a couple of months or so, not really wanting to try to find a
different SCM system (as I really like the concepts that Subversion
entails), but not trusting the backend to the number one most important
asset of our company. After much thought, and some newer revs of
Subversion, along with issues with VSS, I got back on the bandwagon and
tried the FSFS backend (I figured it was likely close enough to stable
at that time - 1.1 RC2). With the EXACT same migration script on the
EXACT same VSS database, the entire repository flowed over without any
problems with Subversion. I'm still working on the final run of the
conversion, as I'm implementing labels -> tags in the script. So, to
summarize, I have little, if any, faith in BDB as a backend to
Subversion, regardless of how many anecdotal stories I read about. If
it is this complex to get set up that I can't seem to get it in three
attempts, then that in and of itself is reason enough for me to use
something else.
Scott Palmer wrote:
>
> On Sep 17, 2004, at 1:20 AM, Greg Goodrich wrote:
>
>> As far as I'm concerned, bdb, at least with Subversion, is NOT AN
>> OPTION.
>
>
> I too noticed that BDB problems seem to account for a lot of the
> messages on this list. Just as some say they never have BDB "wedge" I
> can say I've never lost data with VSS - but I don't think many people
> would say that VSS is a good choice :)
>
We've not "knowingly" lost contents of files in VSS, but then part of
that is because of good backups, not because of VSS. I do know that
we've lost "information", such as the time that a checkin occurred. It
seems that (in our VSS db anyway) the dates tend to be one of the common
"corruption" spots in VSS. To us, this can come into play in tracking
down a client issue (though not necessarily often). It is disconcerting
enough that MS's own best practices document recommends running the
analyze tool at least once a week, as it points towards them knowing of
issues with it.
>> I then noticed RC2 out there, with the promise of "stable" fsfs with
>> 1.1, and decided that I needed to give this a try. I've NEVER had
>> this stick (which makes sense, as the "sticking" is a bdb thing I
>> think). I've also not had problems with it. I've successfully
>> converted our entire repository a couple of times (I'm still not
>> really done, trying to make my migration script handle labels from
>> VSS as well as multiple VSS projects at one time).
>
>
> Are you able to share your conversion scripts? (I'm aware of the one
> on the links page.)
> I'm actually thinking of not converting our VSS database. Instead we
> will simply do new development in subversion and only go back to the
> VSS database when/if we actually need to get that historical
> information. Eventually it will simply be too old to be useful - and
> we can just archive it.
I would need to get Toby's permission for this. He was kind enough to
give me an "early" copy of vss2svn.pl, as we were trying to rapidly get
switched over to Subversion (which never happened, thanks in part to the
problems detailed in this thread). This early copy may have some
proprietary info to his company that he may not want to be made
"publicly available".
>
>> It may be slower (I really don't know, as I couldn't get the bdb
>> version to allow me to convert everything over), but at list it
>> WORKS. I had all but given up on Subversion until I tried the fsfs
>> (I really didn't want to give up on it, as I think it is a very nice
>> app).
>
>
> I find it interesting that you mention that subversion may be slow.
> Since VSS *IS* very slow, I figured you would notice a speed up.
> Though I remember seeing comments about subversion's speed, I also
> recall seeing that some speed issues were addressed in the 1.1 stream.
I've not yet used Subversion in an actual development process yet, so I
really can't speak to its speed as it relates to VSS. I was merely
stating what I thought that I had read somewhere regarding Subversion
with BDB vs FSFS in regards to speed, though I may be in err on this.
>
>> I strongly encourage you to switch at your earliest convenience.
>
>
> I would like to, but the others in the office want to do it at a more
> convenient time in terms of our product development - and I can't
> really ague much with that logic, since we have no evidence that VSS
> is causing ay problems right now.
I think that all those things should be factored into a switch of this
magnitude. You'd be irresponsible to not take your development
timelines into consideration. I'm doing that also.
We also had no "evidence" of VSS problems, at least until we ran analyze
(after about 5 years without running it). I guess it is kind of like a
backup without verify. You may not know that there was an issue until
you need to restore the backup, and at that point you may find that it
isn't there. We recently had a client that thought they were backing up
their system, only to find out later that the hardware was failing them,
and had been for over a year. Of course they found out because they
needed to restore....
> The analyze tool that MS recommends your run weekly - is NEVER run
> on our VSS database unless we notice something a bit weird - it has
> happened maybe twice that we decided to run it. It always complains
> about the database, but the errors it complains about never affect our
> day to day development. Maybe I should take back my statement that
> we have had no loss - we have had no significant loss. I.e. someone
> notice that changes they submitted didn't seem to be there, and they
> submitted them again and we just moved on. That's the sort of thing
> that freaks me out and makes me want to switch, but because it only
> happened once or twice and never caused us any down-time nobody else
> is in a rush to switch.
>
> Anyway I am making progress and it looks like a switch may be in our
> future. So until then I'm tracking subversion's progress, and
> particularly the problems I see reported here that might affect us.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
--
*Greg Goodrich*
Development Manager
*MediNotes Corporation*
1025 Ashworth Road, Suite 222
West Des Moines, IA 50265
Phone: 515.327.8850 ext. 251/
/Fax: 515.327.8856
<http://www.medinotes.com>
*Charting Plus - "The Best EMR Value on the Market!"
**www.medinotes.com* <http://www.medinotes.com/>
Received on Tue Sep 21 19:16:02 2004