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
Received on 2008-07-08 19:52:29 CEST