> I'd like to hear from people with a large user base who switched from
> another VCS to subversion, and how their users coped with the branches
and
> tags being in a different directory, the fact that they can't "switch"
the
> current directory to a different tag or branch, the problem of
forgetting
> to
> add "trunk" when checking out and getting GiB of files instead of MiB,
> etc...
We, fairly recently moved from PVCS Version Manager to svn. It took a
while for people to get used to it. But, the biggest adjustment was
going from get (w/lock) - edit - checking to checkout - edit - commit.
They didn't trust svn to not loose their stuff when they did updates.
They didn't trust merging of two users edits would ever possible work.
We also have our QA people using it to. To check in silktest scripts.
And doc is not using it to check in doc assets which were previously
just an unversioned directory on the server.
Frankly the trunk / branch / tag directories made a lot more sense to
all of us than the file based labels and branching used in PVCS. As a
matter of fact, we never used branching in PVCS because it just seemed
too complicated.
Also, we love the increased performance. Putting a label on a project in
PVCS could take 10minutes or more, even on our smaller projects
(although the newer client/server versions helped). Creating a tag with
svn takes seconds.
BTW: You CAN switch a WC to point to a different branch if you want.
But, we tend to check out branches separately from trunk in order to
easily keep it straight what version we are working on rather than
having to check the WC info all the time.
What they do have trouble with has been merging. Svn 1.5 has helped this
quite a bit. However, it is still a bit difficult because we do have
some binary assets that can't be merged. So, if there are edits in trunk
and branch to one of these a manual edit needs to happen to apply the
changes in one folder to the other, rather than a simple merge.
But, I am considering changing our work flow to match the svn souce code
methods. Where they branch for release and they don't do development in
the release branch but only merge in selectively from trunk as issues
are fixed or for hotfixes or whatever. I think this would solve the
binary file issue since there would only be one path (trunk) where
changes are actually made. I'm not sure how this will work for major
refactorings though.
> to
> add "trunk" when checking out and getting GiB of files instead of MiB,
> etc...
You don't have to use the word trunk. That is just a convention. You
could change the name. Training and experience is your friend.
> Is there any way to hide this from the users, and make svn act more
like
> CVS
> or Mercurial ?
I really don't think hiding this is the best idea. Train your users on
what is happening. Have them read the concepts and process sections of
the svn book.
Hth,
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1041283
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-21 16:08:27 CET