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.
James.
Kylo Ginsberg wrote:
> Rory,
>
> Some gotchas we've run into (migrating a user-base/repository after 8
> years with CVS):
> * you need to track your merges manually to avoid double merges; with
> svn 1.5 this need is reduced for some common cases
> * svn makes merges easy and makes renames easy *but* merges of renames
> are not handled properly and require manual intervention
> * social issue: easier branching/merging leads to *more*
> branching/merging; developers "get" this to varying extents, and we've
> had to formalize our processes more than we expected to compensate.
> This social/training issue is somewhat compounded by technical issues
> like the above -- not only must we explain merging concepts and
> mechanics but we must explain where some of the minefields lie.
>
> Some other items to be aware of if moving from cvs -> svn:
> * permissions are more awkward to manage compared to cvs where you
> could just set file permissions within the cvs repository
> * poor support for revision graphs; with cvs this was easy (on a file
> basis) b/c all history for a file was in a single file in the
> repository; for svn this can be quite a bear to extract; there are 3rd
> party solutions
> * no support for cvs "modules"; our team relied on these in part to
> avoid source organization; we've scripted around this in svn
>
> All that said, we're getting a lot out of svn and it was well worth
> the switch. Just nice to be educated about issues up front ;>
>
> Kylo
>
> On Tue, Jul 8, 2008 at 8:34 AM, Rory Clark <roryslists_at_clarkzoo.org> wrote:
>> The raised question was about merging more than about branching and the
>> "gotchas" around it. Can you give me any insight as to what those might be?
>> The person in who raised it didn't go into details.
>>
>>
>>
>> Thanks!
>> Rory
>>
>> -----Original Message-----
>> From: Mcgee, Mark [mailto:mark.mcgee_at_credit-suisse.com]
>> Sent: Tuesday, July 08, 2008 5:17 AM
>> To: users_at_subversion.tigris.org
>> Subject: RE: Questions about Subversion...
>>
>>> Does SVN support the ability to apply policies over directories? For
>>> example, can I limit access to specific directories under the tree to
>>> different groups with different levels reading and writing
>>> capabilities? Can I take it one step further and lock down the tree
>>> and prevent commits to it, like in the situation where we have a
>>> release candidate and we don't want anyone making unapproved
>>> check-ins?
>> Others have answered on per-directory access control, but re: releases,
>> seeing as every commit to a SVN repository is effectively a "branch"
>> because its revision history is for the whole repository and not per file,
>> you can build a release from any revision you like without any need to stop
>> ongoing develop on the Trunk.
>>
>> Branching is no big deal in SVN, it is effectively making a copy/shortcut to
>> a revision in history - the info you need is all in the subversion book
>> under branching and tagging.
>>
>> It'll probably be useful for you to read this section
>> http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4.1
>> which describes the "best" practice usage of SVN - i.e. develop new features
>> in Trunk, release to a branch and test, and then tag and release the
>> "tagged" code.
>>
>> The tag is an unchanging snapshot in time, the branch will start off that
>> way, but may be updated for interim fixes/releases to released code, and new
>> work continues in trunk.
>>
>> Regards,
>> Mark
>>
>> ============================================================================
>> ==
>> Please access the attached hyperlink for an important electronic
>> communications disclaimer:
>>
>> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
>> ============================================================================
>> ==
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-10 13:40:02 CEST