At 10:24 AM 5/5/2005 -0500, you wrote:
[snip]
>I thought I posted a wordy reply to this effect in response to Ben
>Collins, but I'm not sure it ever made it. The gist of it was this: we're
>not the Army. If this is going to happen, it will be because I do it, not
>because I ask for it to become some kind of policy. There's no vertical
>hierarchy to stamp this down. The idea is to put it in place, get the
>project organized, lay in some commits so that people can follow a good
>example, and then work with everyone individually to bring in their
>involvement. The query was in regard to minimizing the disruption to
>everyone else. Perhaps I overplayed the secrecy angle, but with a name
>like "Subversion," I'm not sure what you'd expect.
>
>The square question might have been, "How might I deploy Subversion and
>bring in the rest of my team incrementally?" The assumption is that
>deployment can be either monolithic face-on style, or cooperative and
>adaptive to the existing workflows of other contributors. I'm trying to do
>this along the lines of the latter, that's all.
I am doing something not too different from what you are proposing. We
have three developers using another revision control system that none of us
like or trust much. But we paid for it, and arguing that we should take
time out of our development schedule to replace it with something "free"
(which means "takes a lot of time to get going" to management) is a tough
sell. Installing Subversion doesn't take long, but learning how to use it,
integrating it with our code editors, setting up backup for it, etc. is
complex enough that I wasn't comfortable recommending doing it all at once.
What I did instead was install TortoiseSVN on my computer and start running
it in parallel with our existing version control system. Every time I
commit, I do it on both systems. When I merge a branch, I can do it with
one system then repeat with the other (restoring the pre-merge files first)
and compare the results, or just take the results of the merge on one and
check it into the other. It takes a little extra time to repeat the
operations, but it has given me a safe way to learn.
My next step is to move the svn file store from my machine to a server and
set up svnserve (I could use Apache instead). I will have to figure out
how to include the file store in the automatic backups, but nothing should
have to change about how I use it. Then I can help my co-workers learn to
use it (still in parallel with our existing system), and once they are
convinced that it is a viable replacement, drop the old system.
A similar process might work well in your situation. If you create an
empty directory in svn, then "add" the files from your network share to it,
you won't have to do an after-hours swap on that directory. Others may
notice the new .svn subdirectories, but the files they are used to seeing
won't even temporarily go away (remember that the amount of disk space used
on the network share will approximately double). You can then check out a
working copy to develop in. When you are ready to move your changes back
to the network share, you will probably want to commit "everyone elses'"
changes to svn (possibly as a different user), update your working copy (to
merge any files that were changed on both sides), then commit your wc and
finally update the network share. If you are sure that the files you
changed weren't changed by anyone else or you don't mind working out any
conflicts on the network share rather than in your wc, you could reverse
the order, committing your wc first, then updating the network share (any
necessary merges would happen during the update), then updating your wc.
Even if you never got anyone else to migrate to svn, there would be
advantages for you. Not only would you have a record of everything you
changed and when, but you won't have to worry about overwriting anyone
else's changes; the changes you make will automatically be merged. Svn
will remind you when you add a file to your wc, so you can't forget to
share it. You won't have to keep track of which files to copy back to the
network share; that will be automatic.
Once you are comfortable working with the new system, you can work on
getting your co-workers to migrate one at a time. Once you get a critical
mass, there will be pressure on the holdouts to convert, as it will save
the rest of you the effort of keeping the network share up to
date. Eventually it can just go away, and svn will become the "master copy".
Let us know how it works out; it should be interesting :)
Steve
P.S. I haven't used Subversion for very long, so I may have some of the
details wrong, or there may be a better way to do things.
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve@link-comm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 6 19:59:01 2005