Hi Tom!
> I don’t really want to keep the two systems going long term.
As others have suggested, set a date and do the switch. Anything else
is going to be a pain. We can see it, you describe it to us ;-)
We have just done it at my company. Going from VSS to SVN. We set a
date and changed. Couldn't have gone better.
They way I did it was this:
Behind the scenes I was optimizing an automated conversion until it
was really fully automatic. So before people went home, everyone
checked their stuff in, I started the conversion over night and the
next day VSS was no more.
> just to give you an idea of what I’m dealing with here probably
> don’t even now how to open the command prompt window anymore.
I do hate answer like this myself, but sorry, here it comes:
Teach them the proper way! Really, they will notice how much easier it
is! What you describe is just calling out for using something like
SVN...
And with TortoiseSVN it couldn't be easier.
If I do understand you correctly, source code gets passed around and
one day it comes back to you or your company, right? So either you or
some guy at ur place diffs that against the VSS database and checks in
the changes. Right so far?
If you want to keep it like that, well, just copy the stuff you get
back from them into your working copy and try to commit it. Or if you
need to check it before committing, run a diff. It is now possible and
should be really easy.
If there are no conflicting changes, you don't even have to merge by
hand. SVN will do it for you.
But I would go the other way:
Teach people how to use SVN! If it is like you say, it must take ages
to diff all those changes someone might send back! Either give the
other companies write access to your repository or if that is
inacceptable, have them send in patch files! TSVN can create them very
easily. No command line stuff needed.
Or you could just give other companies write access to only the
branches folder and they work in there. When they are done, they tell
you and you try to merge it back in. Again, diffing is then more than
easy. It is all in the repository.
I am going to repeat myself, but looking at what you describe, if you
do have the time, write up clear instructions and tell everyone who is
to work with your sources to stick to these rules. After lots of
complaining (I know they will ;-)) they will soon realize how very
much easier the whole thing is!
Trust me, I went through it in my company. How reluctant were they and
now that it is done they start to see how much nicer it is!
> As you all have been telling me, it’s a different world… I can
> accept that that is the fact, but I’m the type that needs to work
> through those differences in detail and I need to understand where,
> when and WHY the particular difference exist.
Okay, let me try to sum it up:
- People do get "working copies" now with VSS (get latest version)
- They modify their "working copy"
- They send it back to you
- You check out the files you need and diff them
- You manually insert the changes they made
You know what this is? This is almost the SVN model! The only
difference is, that currently only ONE person can check something in
(or in SVN terms: "commit") and that poor person has to diff the whole
sources and manually insert changes!
With SVN the above would look like this:
- People check out their working copies
- People modify their working copy
- People try to commit it. Changes will be auto merged, unless there
are conflicts
If you do need to check changes before they are actually going to be
committed, have people work in branches and then merges those branches
to trunk.
Really, what you are doing now, is already halfway there, but VSS is
getting in your way with it's lock-modify-unlock model.
Was this helpful? If not, ask again :-)
Cheers, Ingo =;->
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 21 22:05:27 2007