You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Eric S. Raymond" <es...@snark.thyrsus.com> on 2004/09/10 04:55:49 UTC
Out of date errors just after a revert
The berlios.de people fixed my stuck group-write bit, but the
repository remains in a state I can't diagnose.
I was trying to commit changes to a file called gpsprobe when things went all
pear-shaped. svn now complains the file is out of date and won't do
the commit. What puzzles me is that this behavior continues even after
I explicitly revert gpsprobe.
Isn't revert supposed to refresh the baseline copy? How can it be
out of date at that point?
(Yes, I tried doing another svnadmin recover. No bomb-out this time,
but no help either.)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
"...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances."
-- Harry Browne, 1996 USA presidential candidate, Libertarian Party
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by kf...@collab.net.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> Turns out there's an existing FAQ item this fits under.
Applied (tweaked) in r10883. Thanks!
-Karl
> Index: project_faq.html
> ===================================================================
> --- project_faq.html (revision 10870)
> +++ project_faq.html (working copy)
> @@ -1428,10 +1428,29 @@
> working copy is out of date?</a></h3>
>
> <p>
> -When you commit, Subversion bumps the revision numbers of all nodes the commit
> -touches. This means that in a single folder, the files and folders might
> -be at different revisions, depending on when you last committed them.</p>
> +There are at least two kinds of situation that can cause this. One
> +involves debris from a failed commit; the other can be triggered by
> +the presence of mixed revisions in a working copy.</p>
> <p>
> +You may have had a commit that went sour between the time the new revision
> +was added in the server and the time your client performed its
> +post-commit admin tasks (including refreshing your local text-base
> +copy). This might happen for various reasons including (rarely)
> +problems in the database back end or (more commonly) network dropouts
> +at exactly the wrong time.</p>
> +<p>
> +If this happens, it's possible that you have already committed the very
> +changes you are trying now to commit. Try reverting again, and then
> +running 'svn update'. Only 'svn update' refreshes the text-base; a
> +revert doesn't do that.
> +<p>
> +Occasionally you may see this error without a failed commit in the
> +recent past. When you commit, the Subversion client only bumps the revision
> +numbers of all nodes the commit touches (not of all nodes). This
> +means that in a single working copy, the files and subdirectories
> +might be at different revisions, depending on when you last committed
> +them.</p>
> +<p>
> For certain operations (deletes and property modifications), if the repository
> has a more recent version of the node, the commit will be rejected, to prevent
> data loss.</p>
> @@ -1442,7 +1461,8 @@
> <a href="http://svnbook.red-bean.com/">Version Control with Subversion</a>
> for details.</p>
> <p>
> -To prevent this error, simply update your working copy using:</p>
> +In either case, you can clean up this error by updating your working
> +copy using:</p>
>
> <pre>
> svn update working-copy
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> Would be so kind as to work up a patch against www/project_faq.html?
> I'd be happy to review/apply it after you've done so. If you feel
> like taking the very text of the description I mailed, go for it.
Turns out there's an existing FAQ item this fits under.
Index: project_faq.html
===================================================================
--- project_faq.html (revision 10870)
+++ project_faq.html (working copy)
@@ -1428,10 +1428,29 @@
working copy is out of date?</a></h3>
<p>
-When you commit, Subversion bumps the revision numbers of all nodes the commit
-touches. This means that in a single folder, the files and folders might
-be at different revisions, depending on when you last committed them.</p>
+There are at least two kinds of situation that can cause this. One
+involves debris from a failed commit; the other can be triggered by
+the presence of mixed revisions in a working copy.</p>
<p>
+You may have had a commit that went sour between the time the new revision
+was added in the server and the time your client performed its
+post-commit admin tasks (including refreshing your local text-base
+copy). This might happen for various reasons including (rarely)
+problems in the database back end or (more commonly) network dropouts
+at exactly the wrong time.</p>
+<p>
+If this happens, it's possible that you have already committed the very
+changes you are trying now to commit. Try reverting again, and then
+running 'svn update'. Only 'svn update' refreshes the text-base; a
+revert doesn't do that.
+<p>
+Occasionally you may see this error without a failed commit in the
+recent past. When you commit, the Subversion client only bumps the revision
+numbers of all nodes the commit touches (not of all nodes). This
+means that in a single working copy, the files and subdirectories
+might be at different revisions, depending on when you last committed
+them.</p>
+<p>
For certain operations (deletes and property modifications), if the repository
has a more recent version of the node, the commit will be rejected, to prevent
data loss.</p>
@@ -1442,7 +1461,8 @@
<a href="http://svnbook.red-bean.com/">Version Control with Subversion</a>
for details.</p>
<p>
-To prevent this error, simply update your working copy using:</p>
+In either case, you can clean up this error by updating your working
+copy using:</p>
<pre>
svn update working-copy
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@thyrsus.com> writes:
> > Revert simply rebuilds the working from from the pristine text-base in
> > the .svn directory. If you had a commit that went sour between the
> > time the new revision was added in the server, and the time your
> > client performed its post-commit admin tasks, then it's possible that
> > you have already committed the very changes you are trying now to
> > commit.
> >
> > Try reverting again, and then running 'svn update'. Chances are good
> > that the server will send you the very changes you're trying to send
> > *it*. :-)
>
> Ahhhh. So only "svn update" refreshes the baseline. I grok.
>
> That procedure worked, and you've given a good explanation.
Why, thank you.
> Would you please add it to the FAQ? I am unlikely to be the last
> person to trip over this. The question should probably be something
> like,
>
> "After a failed commit and database recovery, I get "out-of-date" errors
> when trying to finish the commit."
Actually, it should be genericized a bit by striking the " and
database recovery". This can happen for various reasons that don't
require recovery (network outage, etc.).
> And the answer should end by noting that only svn update refreshes the
> text-base.
Would be so kind as to work up a patch against www/project_faq.html?
I'd be happy to review/apply it after you've done so. If you feel
like taking the very text of the description I mailed, go for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by "Eric S. Raymond" <es...@thyrsus.com>.
C. Michael Pilato <cm...@collab.net>:
> "Eric S. Raymond" <es...@snark.thyrsus.com> writes:
>
> > Isn't revert supposed to refresh the baseline copy? How can it be
> > out of date at that point?
>
> Revert simply rebuilds the working from from the pristine text-base in
> the .svn directory. If you had a commit that went sour between the
> time the new revision was added in the server, and the time your
> client performed its post-commit admin tasks, then it's possible that
> you have already committed the very changes you are trying now to
> commit.
>
> Try reverting again, and then running 'svn update'. Chances are good
> that the server will send you the very changes you're trying to send
> *it*. :-)
Ahhhh. So only "svn update" refreshes the baseline. I grok.
That procedure worked, and you've given a good explanation. Would you please
add it to the FAQ? I am unlikely to be the last person to trip over this.
The question should probably be something like,
"After a failed commit and database recovery, I get "out-of-date" errors
when trying to finish the commit."
And the answer should end by noting that only svn update refreshes the
text-base.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by Ray Miller <ra...@sysdev.oucs.ox.ac.uk>.
On Fri, Sep 10, 2004 at 12:21:00PM +0200, L?bbe Onken wrote:
> Marc Haisenko wrote:
>
> >
> >You should have done "svn revert foo" instead of "svn revert ."
> >
> Thanks for your hint. That does the job, but only if I remove foo/bar
> from my WC before. If I just do the following I get an working copy not
> locked:
> ---SNIP---
> D:\TESTPR~1\xxx>svn add foo
> A foo
> A foo\bar
>
> D:\TESTPR~1\xxx>svn revert foo
> svn: Working copy 'foo/bar' not locked
>
> D:\TESTPR~1\xxx>svn st
> A foo
> A foo\bar
> ---SNIP---
>
> Now is that logical?
Yes. Unlike most of the subversion commands, 'svn revert' is not
recursive. 'svn revert -R foo' should do what you want. (If bar had
been a file rather than a directory, 'svn revert foo' would have been
sufficient.)
--
Ray Miller, Unix Systems Programmer & Team Leader
Systems Development & Support, Computing Services, University of Oxford
Re: Out of date errors just after a revert
Posted by Philip Martin <ph...@codematters.co.uk>.
Lübbe Onken <l....@rac.de> writes:
> D:\TESTPR~1\xxx>svn add foo
> A foo
> A foo\bar
>
> D:\TESTPR~1\xxx>svn revert foo
> svn: Working copy 'foo/bar' not locked
You need 'svn revert -R foo' for that to work. Revert is deliberately
non-recursive by default since reverts can be hard to undo. Subversion
is not always consistent here, if bar is a file the non-recursive
revert will work.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by Lübbe Onken <l....@rac.de>.
Marc Haisenko wrote:
>
> You should have done "svn revert foo" instead of "svn revert ."
>
Thanks for your hint. That does the job, but only if I remove foo/bar
from my WC before. If I just do the following I get an working copy not
locked:
---SNIP---
D:\TESTPR~1\xxx>svn add foo
A foo
A foo\bar
D:\TESTPR~1\xxx>svn revert foo
svn: Working copy 'foo/bar' not locked
D:\TESTPR~1\xxx>svn st
A foo
A foo\bar
---SNIP---
Now is that logical?
if I 'svn del foobar' and find out that I made a mistake, I have to 'svn
revert .', which is logical, since 'foobar' is no longer visible to me
and it's an operation on foobars parent folder.
if I 'svn add foobar' and find out that I made a mistake, I have to 'svn
revert foobar', which doesn't even do the job without me moving away
foobar first?!?
This is not logical to me, because I'd expect 'svn revert .' to restore
my current folder to its original condition.
Cheers
- Lübbe
--
___
oo // \\ TortoiseSVN
(_,\/ \_/ \ The coolest Interface to (Sub)Version Control
\ \_/_\_/> http://tortoisesvn.tigris.org
/_/ \_\
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 10 September 2004 09:15, Lübbe Onken wrote:
> Is that really true? A colleague managed to scrap his woking copy by
> doing the following.
> - svn up -> so there are no uncommitted changes.
> - "svn add foo" a folder inside his working copy
> - suddenly notice that there was a subfolder (foo/bar), that he didn't
> want to add.
> - "svn revert ."
> - remove the annyoing subfolder (bar)
> - retry to add foo -> "svn: warning: 'foo' is already under version
> control" - "svn ci" -> "Working copy 'D:/TESTPR~1/xxx/foo/bar' not
> locked" - "svn cleanup" -> no comment
You should have done "svn revert foo" instead of "svn revert ."
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by Lübbe Onken <l....@rac.de>.
C. Michael Pilato schrieb:
> "Eric S. Raymond" <es...@snark.thyrsus.com> writes:
>
>
>>Isn't revert supposed to refresh the baseline copy? How can it be
>>out of date at that point?
>
>
> Revert simply rebuilds the working from from the pristine text-base in
> the .svn directory.
Is that really true? A colleague managed to scrap his woking copy by
doing the following.
- svn up -> so there are no uncommitted changes.
- "svn add foo" a folder inside his working copy
- suddenly notice that there was a subfolder (foo/bar), that he didn't
want to add.
- "svn revert ."
- remove the annyoing subfolder (bar)
- retry to add foo -> "svn: warning: 'foo' is already under version control"
- "svn ci" -> "Working copy 'D:/TESTPR~1/xxx/foo/bar' not locked"
- "svn cleanup" -> no comment
D:\TESTPR~1\xxx>svn st
A foo
! foo\bar
now he can't get rid of foo and bar anymore. The only solution we found
was to to a fresh checkout and start from scratch.
Cheers
-Lübbe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Out of date errors just after a revert
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Eric S. Raymond" <es...@snark.thyrsus.com> writes:
> Isn't revert supposed to refresh the baseline copy? How can it be
> out of date at that point?
Revert simply rebuilds the working from from the pristine text-base in
the .svn directory. If you had a commit that went sour between the
time the new revision was added in the server, and the time your
client performed its post-commit admin tasks, then it's possible that
you have already committed the very changes you are trying now to
commit.
Try reverting again, and then running 'svn update'. Chances are good
that the server will send you the very changes you're trying to send
*it*. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org