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

RE: Working copy locked problem

From: James Oltmans <joltmans_at_bolosystems.com>
Date: 2007-02-06 18:13:02 CET

I and my users would also prefer not to have to check things out again
because our checkout takes about 30 mins (yeah, I know that's insane,
but 30,000 files and a gig of data over http on the intranet does that,
we're working on fixing that problem but I doubt we'll get below 5 mins
for a checkout).

Anyway I agree with Steve, the WCs shouldn't be so fragile. IMO .svn
folders should be a nicety to cut down on repo accesses and response
times NOT a source of frustration to users who need to write dump
programs to capture the state of their system.

James

-----Original Message-----
From: Steve Bakke [mailto:steven.bakke@amd.com]
Sent: Tuesday, February 06, 2007 7:11 AM
To: Les Mikesell; Bolstridge, Andrew
Cc: users@subversion.tigris.org
Subject: Re: Working copy locked problem

On 2/6/07 9:01 AM, "Les Mikesell" <lesmikesell@gmail.com> wrote:

>
>> I've been in situations where subversion has gotten confused with an
>> added folder, and the end solution was to delete the entire working
tree
>> and checkout again, with a fair amount of copying local files to and
>> from a temporary directory.
>
> If you had committed your work after every each change worth saving, a
> fresh checkout would be an easy solution, not just for you, but for
> anyone else working on the code, or to let you pick it up on a
different
> machine. If you have a 'clean trunk' policy where someone is bothered
by
> work in progress there, copy to a branch for the intermediate work and
> merge it back when appropriate. The point of a revision control
system
> is that you put your revisions in there.

That's a poor excuse for what are bugs in the client working copy code.

Admittedly, I haven't managed to nail down a specific issue, but I've
had
similar problems in the past. You can't just dismiss it by saying "just
commit more often". That's like telling somebody with a crash-prone
tool to
hit save early and often. Yes, it may help prevent data loss, but it
doesn't really solve the problem. Subversion working copies seem a bit
fragile to me. I think that some of this may be due to the fact that
while
operations on the repository are atomic, operations on your working copy
are
not. As a result, your WC can get into weird intermediate states.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 6 18:13:34 2007

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

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