You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Schmitt <sc...@TI.Uni-Trier.DE> on 2003/06/05 07:10:40 UTC
"svn move" broken?
Dear SVN developers,
today I noticed a very strange behavior of svn.
In a project with several subdirectories, I moved some files from one
subdirectory to another (svn move subdir1/fileXXX subdir2/subsubdir2/.).
Whenever I moved two or three files, I committed the changes in both
subdirectories with "svn commit subdir1 subdir2". Everything seemed to
work well.
Then, I decided to remove the whole subdir from which I had moved away
the files (sub remove subdir1). Again I committed my changes (svn commit
subdir1). Unfortunately, I got the following error message:
Deleting subdir1
svn: Transaction is out of date
svn: Commit failed (details follow):
svn: out of date: `/project/subdir1' in txn `xp'
svn: Your commit message was left in a temporary file:
svn: '/home/TI3/schmitt/project/svn-commit.tmp'
First of all, this message is absolutely confusing. Please, please
change it to make it more suitable for dummy users like me!
After all while, I found out what this message means and I ran "svn
update subdir1". And here comes the surprise:
D subdir1/FileXXX1
D subdir1/FileXXX2
...
Although all previous commits were successful (at least I thought so),
svn did not update my working copy correctly! Or, more precisely, it did
not update the meta information in my working copy, since the real files
had definitely gone before! And there was no other user working in this
project at the same time.
Do you have any idea how this could happen?
System information: SVN 0.23, module ra_local, DB 4.1.25, SuSE 8.1, gcc
3.2.0.
Kind regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Stefan Monnier wrote:
>>>>>>"Michael" == Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
>>>>>>
>>>>>>
>> Deleting subdir1
>> svn: Transaction is out of date
>>
>>
>
>Huh ? How can a transaction be out-of-date ?
>
Because a SVN transaction does not equal a DB transaction.
SVN transactions are long-lived. So they can get out-of-date.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
>> > Deleting subdir1
>> > svn: Transaction is out of date
>> Huh ? How can a transaction be out-of-date ?
>> Maybe it should say "subdir1 is out-of-date" or something.
> A transaction tree can be "out of date" if it is unable to merged into
> the HEAD revision tree. That message is coming directly from
> libsvn_fs.
Hmm... I got once more confused by this funny terminology.
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
"Stefan Monnier" <mo...@rum.cs.yale.edu> writes:
> >>>>> "Michael" == Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
> > Deleting subdir1
> > svn: Transaction is out of date
>
> Huh ? How can a transaction be out-of-date ?
> Maybe it should say "subdir1 is out-of-date" or something.
A transaction tree can be "out of date" if it is unable to merged into
the HEAD revision tree. That message is coming directly from
libsvn_fs.
But the message *does* say that subdir1 is out-of-date, if you keep
reading the error message:
svn: out of date: `/project/subdir1' in txn `xp'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Stefan Monnier <mo...@rum.cs.yale.edu>.
>>>>> "Michael" == Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
> Deleting subdir1
> svn: Transaction is out of date
Huh ? How can a transaction be out-of-date ?
Maybe it should say "subdir1 is out-of-date" or something.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Jani Monoses <ja...@iv.ro>.
On 05 Jun 2003 10:26:43 -0500
Ben Collins-Sussman <su...@collab.net> wrote:
> Jani Monoses <ja...@iv.ro> writes:
>
> > I had to look at the source to understand what 'out of date' means
> > :).
>
> Yikes. The phrase "out of date" is a basic version-control term. At
I know :) . I meant what out of date means in this context...indeed the
term transaction is the confusing factor here
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
Jani Monoses <ja...@iv.ro> writes:
> I had to look at the source to understand what 'out of date' means :).
Yikes. The phrase "out of date" is a basic version-control term. At
least, it's a basic concept in both CVS and SVN terminology. The SVN
book even defines it in the introductory chapters. If something is
"out of date", that means the repository contains a newer version of it.
> Being in the same message with the word transaction I initially
> thought some transaction started and never completed
Yeah, so maybe the word 'transaction' is just scaring people away. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Jani Monoses <ja...@iv.ro>.
On Thu, 5 Jun 2003 16:36:35 +0200
Michael Wood <mw...@its.uct.ac.za> wrote:
> On Thu, Jun 05, 2003 at 08:21:14AM -0500, Ben Collins-Sussman wrote:
> > Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
> >
> > > Deleting subdir1
> > > svn: Transaction is out of date
> > > svn: Commit failed (details follow):
> > > svn: out of date: `/project/subdir1' in txn `xp'
> > > svn: Your commit message was left in a temporary file:
> > > svn: '/home/TI3/schmitt/project/svn-commit.tmp'
> > >
> > > First of all, this message is absolutely confusing. Please, please
> > > change it to make it more suitable for dummy users like me!
> >
> > What would be less confusing?
> >
> > "Sorry, you attempted to commit '/project/subdir1', but failed,
> > because it is out-of-date."
> >
> > Is it the word "transaction" that is confusing?
> > Because otherwise, the message already says that
> >
> > 1) the commit failed
> > 2) /project/subdir1 was out-of-date
> [snip]
>
> Perhaps something like "/project/subdir1 was out-of-date. Try svn up
> /project/subdir1" would be slightly less confusing? It's not
> immediately obvious to a new user what "blah is out of date" means and
> what to do about it. e.g. "Why would it be out of date? I just
> committed it a moment ago!"
I had to look at the source to understand what 'out of date' means :).
Being in the same message with the word transaction I initially
thought some transaction started and never completed so it was labeled
'out of date' by the repo or BDB or whatever I imagined is in charge of
transactions and that I needed some repository repair in order to clean
those 'not up to date transactions'
I was relieved when I saw in the source I only had to svn up :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Thu, Jun 05, 2003 at 08:21:14AM -0500, Ben Collins-Sussman wrote:
> Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
>
> > Deleting subdir1
> > svn: Transaction is out of date
> > svn: Commit failed (details follow):
> > svn: out of date: `/project/subdir1' in txn `xp'
> > svn: Your commit message was left in a temporary file:
> > svn: '/home/TI3/schmitt/project/svn-commit.tmp'
> >
> > First of all, this message is absolutely confusing. Please, please
> > change it to make it more suitable for dummy users like me!
>
> What would be less confusing?
>
> "Sorry, you attempted to commit '/project/subdir1', but failed,
> because it is out-of-date."
>
> Is it the word "transaction" that is confusing?
> Because otherwise, the message already says that
>
> 1) the commit failed
> 2) /project/subdir1 was out-of-date
[snip]
Perhaps something like "/project/subdir1 was out-of-date. Try svn up
/project/subdir1" would be slightly less confusing? It's not
immediately obvious to a new user what "blah is out of date" means and
what to do about it. e.g. "Why would it be out of date? I just
committed it a moment ago!"
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Michael Schmitt <sc...@TI.Uni-Trier.DE>.
Michael Wood wrote:
>>Yes, definitely. You could even be more explicit:
>>
>> "Someone else has updated this file. Please run 'svn update'" (or
>>something similar)
>>
>>
>But in this case this error does NOT mean that someone else updated
>anything. It was about a directory, not a file. The directory was not
>up to date because some stuff had been committed inside of it (instead
>of the directory being committed). The files in the directory that were
>committed, were therefore at revision X+n, but the directory was still
>at revision X.
>
That means svn should give different messages for files and directories.
I think, this shouldn't be too difficult to implement. BTW: Your
explanation above would be a good starting point for an improved svn
error reporting.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Thu, Jun 05, 2003 at 03:38:49PM +0200, Michael Schmitt wrote:
> Ben Collins-Sussman wrote:
>
> >What would be less confusing?
> >
> >"Sorry, you attempted to commit '/project/subdir1', but failed,
> >because it is out-of-date."
> >
> >Is it the word "transaction" that is confusing?
> >
> Yes, definitely. You could even be more explicit:
>
> "Someone else has updated this file. Please run 'svn update'" (or
> something similar)
But in this case this error does NOT mean that someone else updated
anything. It was about a directory, not a file. The directory was not
up to date because some stuff had been committed inside of it (instead
of the directory being committed). The files in the directory that were
committed, were therefore at revision X+n, but the directory was still
at revision X.
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Michael Schmitt <sc...@TI.Uni-Trier.DE>.
Ben Collins-Sussman wrote:
>What would be less confusing?
>
>"Sorry, you attempted to commit '/project/subdir1', but failed,
> because it is out-of-date."
>
>Is it the word "transaction" that is confusing?
>
Yes, definitely. You could even be more explicit:
"Someone else has updated this file. Please run 'svn update'" (or
something similar)
>>Although all previous commits were successful (at least I thought so),
>>svn did not update my working copy correctly! Or, more precisely, it
>>did not update the meta information in my working copy, since the real
>>files had definitely gone before! And there was no other user working
>>in this project at the same time.
>>
>>
>This is a buglet that I believe we're working on. Fortunately, your
>analysis of the problem was completely wrong.
>
>Don't worry, this will be fixed.
>
Phew... I do my best to convince other people that svn is a great
program. However, my collegue and I face serious problems. Of course, we
are not at all able to send you a precise test case :-( At some point we
just drove the repository in a state where some data were lost and the
working copy was broken. No idea how this could happen. It would be nice
if the upper bug could be fixed. I guess this made it easier the
identify "real" problems.
Many thanks for your answer,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Faheem Mitha <fa...@email.unc.edu>.
On Fri, 6 Jun 2003, Greg Stein wrote:
> I wouldn't bother with a bug report... we just recently removed those
> info pages from our installation. Reason is just what you stated: they
> are *not* being kept up to date, so we didn't want to misinform people.
Oh, what a shame. I thought "Great!" when I saw these. I've already sent
the bug report to the Debian BTS. I'll forward your message to the bug
report thread.
Faheem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 06, 2003 at 03:08:47PM -0400, Faheem Mitha wrote:
>
>
> On 6 Jun 2003, Ben Collins-Sussman wrote:
>
> > > Are under-the-hood details like this documented anywhere outside the
> > > source code?
> >
> > It depends on what details you're looking for. The sourcecode is full
> > of commentary, philosophy and design notes.
>
> I was looking for some kind of design document. I see you have something
> along these lines in svn/doc/programmer/design. Hopefully this is being
> kept up to date. The info pages are in the Debian subversion package, but
> there is no link to them from the main info page. Hmm, time to file a bug
> report.
I wouldn't bother with a bug report... we just recently removed those info
pages from our installation. Reason is just what you stated: they are *not*
being kept up to date, so we didn't want to misinform people.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
Faheem Mitha <fa...@email.unc.edu> writes:
> On 6 Jun 2003, Ben Collins-Sussman wrote:
>
> > > Are under-the-hood details like this documented anywhere outside the
> > > source code?
> >
> > It depends on what details you're looking for. The sourcecode is full
> > of commentary, philosophy and design notes.
>
> I was looking for some kind of design document. I see you have something
> along these lines in svn/doc/programmer/design. Hopefully this is being
> kept up to date. The info pages are in the Debian subversion package, but
> there is no link to them from the main info page. Hmm, time to file a bug
> report.
That design doc was written over three years ago, before we ever wrote
a line of code. It's extremely old. But I believe we've cut out all
the factually wrong things; it might provide a good background, or at
least some historic interest.
If you want to understand svn's architecture, the best thing to do is
start by reading the HACKING file. And then read the public svn_*.h
headers, which are full of design explanations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Faheem Mitha <fa...@email.unc.edu>.
On 6 Jun 2003, Ben Collins-Sussman wrote:
> > Are under-the-hood details like this documented anywhere outside the
> > source code?
>
> It depends on what details you're looking for. The sourcecode is full
> of commentary, philosophy and design notes.
I was looking for some kind of design document. I see you have something
along these lines in svn/doc/programmer/design. Hopefully this is being
kept up to date. The info pages are in the Debian subversion package, but
there is no link to them from the main info page. Hmm, time to file a bug
report.
Faheem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
Faheem Mitha <fa...@email.unc.edu> writes:
> However, my understanding is that the version of subdir/file1 in the
> working copy must not differ in content from the version in the repository
> (though it need not be at the same revision) for subversion to allow it to
> be deleted. I just did a test and confirmed this for myself. If I try to
> commit the deletion of a file in the working copy which is different from
> the version in the repository I get
>
> svn: Transaction is out of date
> svn: Commit failed (details follow):
> svn: out of date: `/thesis/trunk/rr.tex' in txn `12'
> svn: Your commit message was left in a temporary file:
> svn: '/home/faheem/cotmp/thesis/svn-commit.tmp'
>
> However, I can delete it as long as there are no differences, even if the
> revision numbers are different.
The rule is: if your working copy has an older version of a file than
the server does, you cannot commit changes to it, nor delete it.
But I'm using the term "version" very loosely here, a version of a
file is not the same as a revision! Revisions 23 through 29 of a file
might all be the *same* version -- absolutely identical. Within the
repository, revisions 23-29 all point to the exact same "version" of
the file (it's a shared node).
> So, I'm not sure what you mean in your second option by
>
> "* if a "new" file1 exists in HEAD, the server sends it".
>
> Is the assumption here that someone has restored/reverted the file in a
> new revision between your `svn delete' and 'svn up'? Or possibly a
> completely different file with the same name? This seems the obvious
> possibility, but I'm just checking in case of misunderstanding.
Yes, exactly. You deleted the file. And then somebody either
resurrected the same file, or added a new file by the same name.
> Are under-the-hood details like this documented anywhere outside the
> source code?
It depends on what details you're looking for. The sourcecode is full
of commentary, philosophy and design notes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Faheem Mitha <fa...@email.unc.edu>.
On 5 Jun 2003, Ben Collins-Sussman wrote:
> Faheem Mitha <fa...@email.unc.edu> writes:
> > 1) The deletes sent to the working copy were in fact redundant. So the
> > local .svn *was* fully up to date with respect to that. Once this
> > buglet has been fixed, no D messages will be sent on doing `svn up' in
> > a similar situation.
> Yes. And in fact, I fixed the bug today. Just update your source. :-)
Yes, I see. Revision 6159, right?
> > 2) In that case, was the problem only that the revision numbers were
> > not synced up to the latest version across the entire directory
> > subdir1 (even though the files themselves in this case were up to
> > date), so it was just a matter of updating the revision numbers for
> > the files in the working copy of that directory (subdir1), and nothing
> > else? Since, as you said in another message to this thread:
> >
> > 1. you cannot delete a file or directory which isn't at HEAD
> > revision in your working copy.
>
> Correct, mostly.
>
> Say subdir1 (and everything inside it) starts out at revision 1.
>
> Now you delete subdir1/file1, and commit the deletion.
>
> What libsvn_wc does is this: it *doesn't* remove the file1 entry from
> subdir1's entries file. Instead, it marks the file1 entry as
> "deleted".
>
> When you run 'svn update subdir1', libsvn_wc tells the server that you
> have revision 1 of subdir1, with file1 already deleted.
>
> The server then compares your working-copy of subdir1 with the HEAD
> version of subdir1, and does one of two things:
>
> * if file1 is also deleted in HEAD, it says nothing; there's no
> differences to send. In which case, libsvn_wc assumes it's
> safe to *completely* remove the file1 entry from the entries
> file, and subdir1 is now marked as being at revision HEAD.
>
> * if a "new" file1 exists in HEAD, the server sends it. In that
> case, libsvn_wc just installs the new file and overwrites the old
> "deleted" entry. (and again, subdir1 is marked at revision HEAD.)
>
> So the bug that was fixed today was that in certain circumstances, a
> commit of three file deletions caused 2 out of 3 file entries to
> (prematurely) disappear completely from the entries file. So during
> an update, libsvn_wc only reported 1 file as "deleted". The server
> then said, "oh, well then, to match HEAD, you also need to delete
> these two other files". Hence the two extra no-op deletions you saw.
>
> Too much information? :-)
No, that is very helpful. I didn't realise there was a plaintext
``entries'' file in .svn till now. I see it says
deleted="true"
when you commit a deletion.
However, my understanding is that the version of subdir/file1 in the
working copy must not differ in content from the version in the repository
(though it need not be at the same revision) for subversion to allow it to
be deleted. I just did a test and confirmed this for myself. If I try to
commit the deletion of a file in the working copy which is different from
the version in the repository I get
svn: Transaction is out of date
svn: Commit failed (details follow):
svn: out of date: `/thesis/trunk/rr.tex' in txn `12'
svn: Your commit message was left in a temporary file:
svn: '/home/faheem/cotmp/thesis/svn-commit.tmp'
However, I can delete it as long as there are no differences, even if the
revision numbers are different.
So, I'm not sure what you mean in your second option by
"* if a "new" file1 exists in HEAD, the server sends it".
Is the assumption here that someone has restored/reverted the file in a
new revision between your `svn delete' and 'svn up'? Or possibly a
completely different file with the same name? This seems the obvious
possibility, but I'm just checking in case of misunderstanding.
Are under-the-hood details like this documented anywhere outside the
source code?
Faheem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
Faheem Mitha <fa...@email.unc.edu> writes:
> 1) The deletes sent to the working copy were in fact redundant. So the
> local .svn *was* fully up to date with respect to that. Once this
> buglet has been fixed, no D messages will be sent on doing `svn up' in
> a similar situation.
Yes. And in fact, I fixed the bug today. Just update your source. :-)
> 2) In that case, was the problem only that the revision numbers were
> not synced up to the latest version across the entire directory
> subdir1 (even though the files themselves in this case were up to
> date), so it was just a matter of updating the revision numbers for
> the files in the working copy of that directory (subdir1), and nothing
> else? Since, as you said in another message to this thread:
>
> 1. you cannot delete a file or directory which isn't at HEAD
> revision in your working copy.
Correct, mostly.
Say subdir1 (and everything inside it) starts out at revision 1.
Now you delete subdir1/file1, and commit the deletion.
What libsvn_wc does is this: it *doesn't* remove the file1 entry from
subdir1's entries file. Instead, it marks the file1 entry as
"deleted".
When you run 'svn update subdir1', libsvn_wc tells the server that you
have revision 1 of subdir1, with file1 already deleted.
The server then compares your working-copy of subdir1 with the HEAD
version of subdir1, and does one of two things:
* if file1 is also deleted in HEAD, it says nothing; there's no
differences to send. In which case, libsvn_wc assumes it's
safe to *completely* remove the file1 entry from the entries
file, and subdir1 is now marked as being at revision HEAD.
* if a "new" file1 exists in HEAD, the server sends it. In that
case, libsvn_wc just installs the new file and overwrites the old
"deleted" entry. (and again, subdir1 is marked at revision HEAD.)
So the bug that was fixed today was that in certain circumstances, a
commit of three file deletions caused 2 out of 3 file entries to
(prematurely) disappear completely from the entries file. So during
an update, libsvn_wc only reported 1 file as "deleted". The server
then said, "oh, well then, to match HEAD, you also need to delete
these two other files". Hence the two extra no-op deletions you saw.
Too much information? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Faheem Mitha <fa...@email.unc.edu>.
On 05 Jun 2003 08:21:14 -0500, Ben Collins-Sussman <su...@collab.net> wrote:
> Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
>> After all while, I found out what this message means and I ran "svn
>> update subdir1". And here comes the surprise:
>>
>> D subdir1/FileXXX1
>> D subdir1/FileXXX2
>> ...
>>
>> Although all previous commits were successful (at least I thought so),
>> svn did not update my working copy correctly! Or, more precisely, it
>> did not update the meta information in my working copy, since the real
>> files had definitely gone before! And there was no other user working
>> in this project at the same time.
>
> This is a buglet that I believe we're working on. Fortunately, your
> analysis of the problem was completely wrong. The metadata *was*
> tracked correctly in your working copy. The files were definitely
> gone already, and subdir1 definitely knew this information.
>
> The "D" actions you see were simply no-ops. The bug here is that
> subdir1 didn't correctly report its state to the server, so the server
> sent redundant commands that did nothing.
>
> Don't worry, this will be fixed.
This has been puzzling me too. I was going to post about this, but I
thought it likely due to my misunderstanding of how subversion
works. So, just to make sure I am understanding this correctly:
1) The deletes sent to the working copy were in fact redundant. So the
local .svn *was* fully up to date with respect to that. Once this
buglet has been fixed, no D messages will be sent on doing `svn up' in
a similar situation.
2) In that case, was the problem only that the revision numbers were
not synced up to the latest version across the entire directory
subdir1 (even though the files themselves in this case were up to
date), so it was just a matter of updating the revision numbers for
the files in the working copy of that directory (subdir1), and nothing
else? Since, as you said in another message to this thread:
1. you cannot delete a file or directory which isn't at HEAD
revision in your working copy.
Faheem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Ben Collins-Sussman <su...@collab.net>.
Michael Schmitt <sc...@TI.Uni-Trier.DE> writes:
> Deleting subdir1
> svn: Transaction is out of date
> svn: Commit failed (details follow):
> svn: out of date: `/project/subdir1' in txn `xp'
> svn: Your commit message was left in a temporary file:
> svn: '/home/TI3/schmitt/project/svn-commit.tmp'
>
> First of all, this message is absolutely confusing. Please, please
> change it to make it more suitable for dummy users like me!
What would be less confusing?
"Sorry, you attempted to commit '/project/subdir1', but failed,
because it is out-of-date."
Is it the word "transaction" that is confusing?
Because otherwise, the message already says that
1) the commit failed
2) /project/subdir1 was out-of-date
3) the commit message was left in a tmpfile
> After all while, I found out what this message means and I ran "svn
> update subdir1". And here comes the surprise:
>
> D subdir1/FileXXX1
> D subdir1/FileXXX2
> ...
>
> Although all previous commits were successful (at least I thought so),
> svn did not update my working copy correctly! Or, more precisely, it
> did not update the meta information in my working copy, since the real
> files had definitely gone before! And there was no other user working
> in this project at the same time.
This is a buglet that I believe we're working on. Fortunately, your
analysis of the problem was completely wrong. The metadata *was*
tracked correctly in your working copy. The files were definitely
gone already, and subdir1 definitely knew this information.
The "D" actions you see were simply no-ops. The bug here is that
subdir1 didn't correctly report its state to the server, so the server
sent redundant commands that did nothing.
Don't worry, this will be fixed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn move" broken?
Posted by Colin Watson <cj...@flatline.org.uk>.
On Thu, Jun 05, 2003 at 09:10:40AM +0200, Michael Schmitt wrote:
> After all while, I found out what this message means and I ran "svn
> update subdir1". And here comes the surprise:
>
> D subdir1/FileXXX1
> D subdir1/FileXXX2
> ...
>
> Although all previous commits were successful (at least I thought so),
> svn did not update my working copy correctly! Or, more precisely, it did
> not update the meta information in my working copy, since the real files
> had definitely gone before! And there was no other user working in this
> project at the same time.
See the Subversion Book, namely the "Directory versions" section under
Appendix A, "Subversion for CVS Users".
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: "svn move" broken?
Posted by Sander Striker <st...@apache.org>.
> From: Michael Schmitt [mailto:schmitt@TI.Uni-Trier.DE]
> Sent: Thursday, June 05, 2003 9:11 AM
[...]
> Although all previous commits were successful (at least I thought so),
> svn did not update my working copy correctly! Or, more precisely, it did
> not update the meta information in my working copy, since the real files
> had definitely gone before! And there was no other user working in this
> project at the same time.
>
> Do you have any idea how this could happen?
Yes, this is expected behaviour. Even if you are the only developer on
a project you should still do:
svn update
svn commit
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org