On 8-Jul-08, at 12:30 AM, Rory Clark wrote:
> My work is contemplating a move from CVS to a new source control
> tool. Currently on the potential "move to" list is Subversion and
> Team Foundation Server, as a few groups already use it. Since I run
> Subversion at home, there were a number of questions I was asked
> that I could not answer.
> One of the risks brought up was one person's encounter with
> database corruption in the repository. I have not seen this in my
> installations. Does anyone have an idea under what conditions, not
> including hardware malfunction, that this could cause this? Is
> there any knowledge about frequency of occurrences?
Never seen db corruption in many years of use (fsfs). Posing the
question to the very large (order of 100,000 revs) Svn projects like
Apache, KDE, Subversion codebase itself – etc (going from memory
here) might be interesting.
> Are there any Visual Studio 2005 and 2008 SCC plug in's for
> Subversion? Do you have links for them? I have found VisualSVN,
> TamTamSVN SCC, and AnkhSVN. Are there any others that you know about?
> Branching and merging was brought as an issue. What are the
> complications around branching and merging that one should be aware
> of and how to mitigate those issues?
1.5 brings vast improvements here, but I haven't used it yet. I've
done complex merges with 1.4, which only takes concentration and care
but basically works as advertised :-)
> Integration of Subversion with LDAP and ActiveDirectory for
> authentication of users. I see in the Red-Bean book that system
> accounts over SSH on SVNSERVE are supported, but does this apply to
> ActiveDirectory on Windows based installations as well? It looks
> like we would need to run an Apache web server for this, even on
> Windows. Is this correct?
> 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-
Received on 2008-07-08 20:32:05 CEST