You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Hendrik <li...@gmail.com> on 2009/08/27 11:35:35 UTC
Re: svn copy breaks on svn update
Concerning Re: svn copy breaks on svn update
Stefan Sperling wrote on 26 Aug 2009, 19:16, at least in part:
> On Wed, Aug 26, 2009 at 07:32:45PM +0200, Jan Hendrik wrote:
> > Hi!
> >
> > It seems that the source of a file svn copied to a new
> > location&name may not be edited until the copy is committed (and
> > probably all working copies updated).
> >
> > In the course of some refactoring to remove duplicate content one
> > user did the following:
> >
> > svn cp /trunk/foo.txt /trunk/common/bar.txt
> >
> > He then edited /trunk/foo.txt to remove the content, leaving only
> > header & footer, and added an include statement for
> > /trunk/common/bar.txt. He did the same on a number of other foo.txt
> > in various directories.
> >
> > He then edited /trunk/common/bar.txt to remove header & footer.
> >
> > He then committed his changes successfully.
> >
> > Updating other working copies now fails in /trunk/common:
> >
> > Conflicted /trunk/common/bar.txt
> > Error in directory /trunk/common
> > Error Can't open file '/trunk/common/bar.txt':
> > Error The system cannot find the quoted file
> >
> > (third line translated as good as possible).
>
> 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.
The usual fact aside that at demo time things don't work the way
they do/did in production, what startles me:
1) I have never before seen the extension ".copied" and was unable
to at least get a glimpse of it during the test update of test-wc2
2) Could it be there is a race condition in svn update? But then
Why would it try to replicate the svn copy when foo1.php even
might have been modified by someone else in an another revision
between the commit of svn copy and svn up?
3) Can it be that the commit of the svn copy together with the
modification has broken the repository in some way? Yet we still
can do commits successfully, even commits touching files from
that trouble revision (from the same working copy). However, we
have not tried any more svn updates today; we cannot afford to
render any further working copy useless nor spend hours for
checking out one after the other at this moment.
Here's the script now:
======
svnadmin create d:/testrepos --fs-type bdb
svn mkdir file:///d:/testrepos/trunk -m "Add trunk"
svn mkdir file:///d:/testrepos/trunk/common -m "Add common"
svn co file:///d:/testrepos/trunk d:/tmp/test-wc1
svn co file:///d:/testrepos/trunk d:/tmp/test-wc2
cd /d d:\tmp\test-wc1
copy \someplace\foo.php foo1.php
copy \someplace\foo.php foo2.php
svn add foo1.php foo2.php
svn ci -m "Add foo?.php in trunk"
; rev3
svn up d:/tmp/test-wc2
svn cp ./foo1.php ./common/bar1.inc
svn cp ./foo2.php ./common/bar2.inc
pause
; edit foo?.php: remove all paragraphs except first & last
; edit common/bar?.inc: remove first & last paragraph
svn st
; A + common/bar1.inc
; A + common/bar2.inc
; M foo1.php
; M foo2.php
svn ci -m "Copy foo?.php to common/bar?.inc, strip out header&footer; remove content from foo?.php"
; committed rev. 4
cd \tmp\test-wc2
svn up
; A common/bar1.inc
; A common/bar2.inc
; U foo1.php
; U foo2.php
; Updated to rev. 4
======
foo.php is attached for peruse.
Any suggestion greatly appreciated.
JH
---------------------------------------
Freedom quote:
Some may try and tell us that this is the end of an era.
But what they overlook is that in America every day is a new beginning,
and every sunset is merely the latest milestone on a voyage that never ends.
-- Ronald Reagan, January 1993
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387846
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn copy breaks on svn update
Posted by Jan Hendrik <li...@gmail.com>.
Concerning Re: svn copy breaks on svn update
Stefan Sperling wrote on 27 Aug 2009, 19:41, at least in part:
> It sounds like a serious problem. But to fix it, we need to isolate
> the cause, and to isolate it, we need more information, and the only
> person on this planet capable of digging for more information about
> this problem is you. Unless someone else shows up who is also seeing
> this problem.
Definitely. I hope I have some information which might tell you
more than it does to myself, and probably even a clue.
> Can you reproduce the problem on a copy of the repository which is
> causing trouble? Can you identify what revision has caused this?
Yes, that's easy (-r1000 for simplicity). IIRC it also was the head
rev. when trouble started while updating wc2. wc2 might have been
at rev. 999 or a bit earlier, but not much. Update obviously broke
when adding the files copied (and edited) to "common" folder as
committed from wc1 in rev. 1000. At this time the source files
(foox.php) already had been updated to rev. 1000, too.
> Have you run svnadmin verify on a copy of the repository?
> What does it have to say?
successful for rev. 1000 (actually checked revs. 995:HEAD, then at
1005, if necessary I can run full verification over the weekend).
Also I could checkout rev. 1000 w/o issues.
Next I did
svn co -r999 (no issues);
svn up (fails, wc locked, should do cleanup); <= on fresh checkout?
svn cleanup (successful);
svn up (successful to rev. 1005, so it seems my fear of ending up
with a repository which would not return revs. 1000+ was
unnecessary).
Also an update of wc1 worked. Dito I was able to update the
"common" folder in another wc, then the wc itself w/o issues. This
wc had no pending modifications (also see below).
> Can you try with a 1.6.x client instead of a 1.5.x one just to see if
> it makes a difference?
Next steps:
completely removed the "common" folder in one of the broken
working copies (wc3) and run svn up. This failed once more in
"common" after adding some of the old files in the folder (but not
all) *and* some of the files copied into per rev. 1000, leaving behind
a couple of the by now well-known triplets *.mine/*.copied/*.rxxx
and the error message "Can't open file ... System can't find file".
Removed "common" once more and did
svn-1.6.4 up (fails, locked)
svn-1.6.4 cleanup (successful)
svn-1.6.4 up (successful)
So the 1.6 client might make a difference indeed. However, here's
probably a clue:
On closer inspection all the working copies broken during update in
the "common" folder had pending modifications and some of these
raised conflicts in the source files (foox.php). This is a factor I did
not try in the test case script.
These errors were expected and resolved using incoming "theirs"
as of rev. 1000. Actually the coincidence of several users working
on non-conflicting parts of foox.php with the necessity to do each
modification in a number of almost identical siblings lead to the
minor refactoring leading to the whole issue of working copies
broken on update.
Can it be this? An issue solved in 1.6? Or just hidden by chance
and apt to raise its head again in the future?
> The most important thing, of course, is don't panic :)
Well, we simply don't have the time to panic ;)
> Even if there is a broken revision in there somewhere, you can still
> restore the repository to a sane state by dumping it incrementally and
> fixing revisions as you go along.
>
> And you do have backups, right?
Every commit is dumped incrementally and appended to a dump
file. After a specific number of revisions the dump file is stored
away, and after a few such dump file cycles another one is done for
the whole range, sometimes additionally even in-between. Of
course, in case the revision of a refactoring is corrupted it might be
very difficult to impossible to re-do that in a way the later revisions
can be loaded.
Looks like the users here have to get used to the commandline
client. They are used to TSVN, but I am told the developer dropped
W2K with 1.6 and will drop XP with 1.7. We never saw any
necessity to go for XP except for one machine (BIOS/hardware
prevents W2K from full operation) and definitely will not go for Vista.
Or do any copy-rename-edit operations only when all working
copies have been committed. Just as we never switch anymore
but checkout another wc ... checkout takes time once, switch the
same amount, but every time.
Thanks for your time, Stefan!
JH
---------------------------------------
Freedom quote:
It is not my intention to do away with government.
It is rather to make it work -- work with us, not over us;
stand by our side, not ride on our back.
Government can and must provide opportunity, not smother it;
foster productivity, not stifle it.
-- Ronald Reagan,
First Inaugural Address, January 20, 1981
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388301
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn copy breaks on svn update
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 27, 2009 at 07:38:31PM +0200, Jan Hendrik wrote:
> 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.
It sounds like a serious problem. But to fix it, we need to isolate
the cause, and to isolate it, we need more information, and the only
person on this planet capable of digging for more information about
this problem is you. Unless someone else shows up who is also seeing
this problem.
> 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:
There must be something different. Else it would just work.
Can you reproduce the problem on a copy of the repository which is
causing trouble? Can you identify what revision has caused this?
Have you run svnadmin verify on a copy of the repository?
What does it have to say?
Can you try with a 1.6.x client instead of a 1.5.x one just to see
if it makes a difference?
> 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.
The most important thing, of course, is don't panic :)
Even if there is a broken revision in there somewhere, you can still
restore the repository to a sane state by dumping it incrementally
and fixing revisions as you go along.
And you do have backups, right?
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387978
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn copy breaks on svn update
Posted by Jan Hendrik <li...@gmail.com>.
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
here);
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.
JH
---------------------------------------
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387960
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: svn copy breaks on svn update
Posted by Stefan Sperling <st...@elego.de>.
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?
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387896
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].