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

Re: svn copy breaks on svn update

From: Jan Hendrik <list.jan.hendrik_at_gmail.com>
Date: Thu, 27 Aug 2009 19:38:31 +0200

Concerning Re: svn copy breaks on svn update
Stefan Sperling wrote on 27 Aug 2009, 15:15, at least in part:

> On Thu, Aug 27, 2009 at 01:35:35PM +0200, Jan Hendrik wrote:
> > > Can you provide a script that starts with an empty repository and
> > > ends with this error?
> >
> > Well, here is a script which should be close enough, except that it
> > does not produce yesterday's experience. IOW with this things work
> > as one would expect. Besides the test file "foo.php" attached.
> I don't understand. The script does not reproduce the problem at all?
> What do you want people to do with foo.php?

I don't understand either what is going on. Definitely I cannot
update any working copy anymore without breaking it the moment
update hits that "common" folder. Yet I can't reproduce it either
with the script.

As far as I can tell the script reproduces what the user did, with
respect to what he had to do, what he says he did, and what the
log tells:

svn cp several files to the "common" folder, renaming them on the
way (foo.php provided as placeholder for those files; I don't know
how to make and edit files by plain batch file in a use case as
edited both the source files and the target files;
committed everything successfully in rev. xxxx.

But updates on other working copies break on those files he had
copied to the "common" folder with the error messages quoted in
my first posting. On *any* working copy, so it's not that just by
coincidence one working copy got corrupted (as said to be
expected and tolerated by design).

What's left behind in "common" are

bar1.inc.rxxxx (size as bar1.inc committed by user per rev. xxxx)
bar1.inc.copied (size as was when originally copied to "common")
bar1.inc.mine (size 0)

bar2.inc.rxxx (size 0)
bar2.inc.copied (size 0)
bar2.inc.mine (size 0)

This is on working copies foo never was copied to bar, which
should just add bar by way of svn update!

As things like that usually hit at the worst moment we can't fool
around endlessly. So I manually copied the changes into the other
users' working copies, and when they tell me they are ready to
commit I copy their changes back into the original user's working
copy and commit (as this is the only working copy knowing about
those files copied to "common"). In our small team this has to
work for the next few days. However, I suppose that we'll find that
the repository has been rendered unusable and therefore lost with
all history.

Freedom quote:

     If some among you fear taking a stand
     because you are afraid of reprisals
     from customers, clients, or even government,
     recognize that you are just feeding the crocodile
     hoping he'll eat you last.
               -- Ronald Reagan


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-27 19:39:30 CEST

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.