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

RE: RE: Re: 'svn cleanup' no workie

From: Peter Yamamoto <yamamotop_at_page44.com>
Date: 2006-03-14 22:39:40 CET

Ok, I'd really appreciate it if anybody has any suggestions or what I
can do to help isolate what causes this problem.

I thought maybe it was the big changes I was doing.

But now I just did an update in order to get a single moved folder, and
all of a sudden my whole workspace seems to be in a bad state wrt
.svn/tmp folders.

After the failed update (note that the folder did move, but then
apparently while trying to update the .svn folders (!!!??? WHY all the
.svn folders in the whole damn workspace!?!) it fails leaving a ton of
them in a bad state.

Update says do a cleanup
Cleanup complains about the lock file in the root.

Cleanup at any lower level complains about the bad state of .svn
folders.

Previous to this I had just committed work to the trunk so my workspace
seemed fine then.

WinXP Pro (both client and server)
Subversion 1.3
TortoiseSVN 1.3.2 5840

Once again, I'm going to have to blow away a ~30Gb workspace (*2 for
.svn poop) and start all over again.

I am really having second thoughts about using subversion as a practical
version control solution at this point.

Peter

-----Original Message-----
From: Peter Yamamoto [mailto:yamamotop@page44.com]
Sent: Tuesday, March 14, 2006 9:34 AM
To: Michael Hipp
Cc: users@subversion.tigris.org
Subject: RE: Re: 'svn cleanup' no workie

I've bulldozer-ing for four days now trying to populate a server
(Windows XP Pro, dav-svn, svn 1.3, xp pro client, tortoise [and cmd line
as well]).

The can't copy from .svn/tmp/[usually entries] to .svn is one of the
repeated problems I have run into.

Note that this in particular repeatedly happed when trying to merge a
transaction that consisted entirely of add's [from a vendor branch to a
trunk workspace].

Very frustrating.
Peter

-----Original Message-----
From: Michael Hipp [mailto:Michael@Hipp.com]
Sent: Tuesday, March 14, 2006 6:08 AM
Cc: users@subversion.tigris.org
Subject: Re: 'svn cleanup' no workie

Ryan Schmidt wrote:
>
> Did something special recently happen with tables.cmd? Was it just
> added, or deleted, or moved to or from where it is now?
>
> Alternately, is there a case sensitivity issue-do you have for example

> both tables.cmd and TABLES.CMD?

System A edited tables.cmd which had otherwise gone unchanged for quite
some time, committed it and then this lock/cleanup problem arose on
System B when I tried to update. I've checked both machines and there is
no sign of anything other than a pure lowercase tables.cmd.

I found a number of articles blaming this sort of problem on case
insensitivity, but I can find no evidence for it here. And the stated
solutions for same were no help.

Alas, to get around the problem I removed a number of large things from
the repo (I'll add them back later sans history) so I could destroy my
working copy and re-checkout. That seemed to be the only way I could get
back working again from a 24 kbps dial-up.

But this has shaken my confidence in svn as my working copy was useless
and the bulldozer method of fixing it is inelegant and often infeasible.

Thanks,
Michael

---------------------------------------------------------------------
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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 14 22:42:54 2006

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.