Posted here: http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=79884
We (and I) used cvs a good bit in past.
With the move to subversion many things are the same or very similar.
It is a good move I think.
The svn backend/database is better IMHO. I did on occasion see some corruption with cvs but
svn is more solid and access methods are more scalable/easier (usually http).
Merging/branching ... :)
We used branches cautiously on cvs for some things.
After moving to svn we're now mostly using branches for all changes, ... larger distributed
development team. BUT you then also have to make time/resources for more testing and merging.
Best practice for branches for both cvs and svn is to rebranch regularily and merge
regularily also (when you can). That is VERY IMPORTANT! Merging lots of code that has changed
in the same area gets complicated very quickly, even with simple changes. You can get merge editors
that help you with this a little but best practice is to minimize merge conflicts.
I believe some tools (git) can do magical things with merges, but I have no experience with that.
We use branches extensively on large projects and it is a good system.
If we didn't use branches users work would conflict with each other more.
If you can have smaller projects with very tight teams and very good communication you can
work without isolating features on branches. You have to figure out how your company/teams
can work best. We build all platforms and regression test projects before branch merges to trunk.
With svn 1.5 and merge tracking (and I believe more coming in future?) things should get a bit
easier. We use tools to help us manage branches. To figure out the correct merge commands (what
revision number of last rebranch and currect revision number ....)
We use Trac for bug/ticketing, managing branches and integrated view of svn.
There are some other ~messy~ things that trip up users with merging.
I don't think I can cover everything but:
* rebranching or merging, if a user does something wrong they can make a bit of a mess
and need someone that really knows svn and revisions to recover from the mess.
Some svn error reports or behaviour doesn't help
* e.g. if user runs a merge command in wrong directory!
(they might see lots of "skipped" warning messages but think they did the correct thing
* if dirs are deleted in svn,
often users local copy has unversioned files (e.g. left over from testing and building) in
dirs, svn up or merge is cautious and will not remove unversioned items so commands can fail
and puzzle users.
This is also problem for svn switch.
* for large projects users over a slower connection some commands will sometimes timeout/fail
it is possible to resume svn command but sometimes svn cleanup is needed
One thing lost from cvs is your commit log.
It's not lost really. Commit log messages are still on ticket branch at those old revisions which
you merged. But on trunk (or parent branch) you only see the merge log message.
Pity because svn blame or svn praise listings are also less useful.
Tagging is different - people seem to not understand it initially and think that cvs has better
tagging. But actually svn has better tagging, every native svn revision number is a tag.
It's easy to have a tags directory.
For users off-site over slow links if you have a large svn repository you have to consider
time taken to checkout or merge or ... You can use svn switch and clean copy of svn to switch from
to make getting a new branch faster. It is better if svn status -u and other commands are fast
so users check carefully what actions they take before running them.
No comments:
Post a Comment