[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Differences between v1.5 and v1.7

From: Andy Levy <andy.levy_at_gmail.com>
Date: Fri, 2 Mar 2012 08:51:47 -0500

On Thu, Mar 1, 2012 at 16:14, Mike Roppolo <mroppolo_at_eatonvance.com> wrote:
> Hello all -
>
> Recently, we made the upgrade from Subversion v1.5 to v1.7.  In the older version, we used a working copy on a Dev Server's shared drive with _svn directories.

This is an anti-pattern, unsupported and strongly discouraged,
regardless of what version of Subversion you're using. So before you
even move from SVN 1.5 to 1.7, you're off the map.

Additionally, using _svn instead of .svn was a hack implemented to
satisfy a bug in old versions of ASP.NET and/or Visual Studio; it
hasn't been really needed for many years, as long as you're staying
current with your software.

> When I upgraded the working directory of the shared drive, the _svn directories disappeared.  Now, when "Developer A" makes a change, the only way "Developer B" can see the file's overlay icon change is with an explicit Update command.
>
> To put this in other terms, let's say I made a change to a file using my work PC and didn't check it in.  Then I go to my co-worker's PC and look at the file.
>
> Under v1.5, the file would have had displayed a Modified icon overlay.
>
> Under v1.7 the file displays a Normal icon overlay.  When my co-worker performs an Update on the file, the icon overlay changes to Modified.
>
> What can we do to make v1.7 operate in the previous way ?

Well, as I said above neither is a supported or recommended
configuration in the first place, so replacing one "broken" behavior
with another isn't really advisable. SVN 1.7 moved to a centralized
WC metadata location with a very heavy reliance upon SQLite. You may
be running into concurrency issues with SQLite which it was never
meant to handle.

Even ignoring any software issues, shared WCs introduce a very high
risk of changes being committed which shouldn't be, and they reduce or
eliminate any accountability - I can commit your changes, and now our
log history cannot be trusted to when it comes to who made what
change, and for what reasons.

The correct solution is to not use a shared working copy at all, and
use Subversion the way it's intended - each user has his own WC that
only he accesses.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2928732

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-03-02 14:52:34 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.