You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Co...@web.de on 2007/02/18 21:59:01 UTC
Break your working copy in 3 easy steps
Hi all,
Assume there are 2 files in the repository which should always be committed together, such as an OpenOffice document and the PDF exported from it:
/root/oo.org/mydoc.odt
/root/pdf/mydoc.pdf
Assume there are pending changes in the doc (exported to the PDF) worth committing.
C:\> svn commit --message "some reasonable message" "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf"
--> OK
Now create more changes and export them again. Repeat the step above.
--> Modified: ...\mydoc.pdf
Error: Commit failed (details follow):
Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
Error: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).
I read on the list about deleting wcprops files, but as I can't find any file of that name, the only way to get around the problem is to copy the changed file, remove the .svn folder and check it all out from scratch, then copy the changed file, again.
Most recent SVN running on most recent Windows XP SP2
Subversion 1.4.3,
apr 0.9.12
apr-iconv 0.9.7
apr-utils 0.9.12
berkeley db 4.4.20
neon 0.26.3
OpenSSL 0.9.8d 28 Sep 2006
zlib 1.2.3
I did try to update the files before committing, same result.
I thought at first the problem is related to TortoiseSVN, but the same problem occurs no matter if I use TSVN or the command line.
What am I doing wrong ?
CU C>
_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Break your working copy in 3 easy steps
Posted by CodeBase <co...@web.de>.
Matt Sickler schrieb:
> did you try `svn update` when that error happened?
Yes I did, same result.
CU C>
>
> On 2/18/07, *CodeBase@web.de <ma...@web.de>* < CodeBase@web.de
> <ma...@web.de>> wrote:
>
> Hi all,
>
> Assume there are 2 files in the repository which should always be
> committed together, such as an OpenOffice document and the PDF
> exported from it:
>
> /root/oo.org/mydoc.odt
> /root/pdf/mydoc.pdf
>
> Assume there are pending changes in the doc (exported to the PDF)
> worth committing.
>
> C:\> svn commit --message "some reasonable message"
> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf"
> --> OK
>
> Now create more changes and export them again. Repeat the step above.
>
> --> Modified: ...\mydoc.pdf
> Error: Commit failed (details follow):
> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
> Error: The version resource does not correspond to the resource
> within the transaction. Either the requested version resource is out
> of date (needs to be updated), or the requested version resource is
> newer than the transaction root (restart the commit).
>
> I read on the list about deleting wcprops files, but as I can't find
> any file of that name, the only way to get around the problem is to
> copy the changed file, remove the .svn folder and check it all out
> from scratch, then copy the changed file, again.
>
> Most recent SVN running on most recent Windows XP SP2
> Subversion 1.4.3,
> apr 0.9.12
> apr-iconv 0.9.7
> apr-utils 0.9.12
> berkeley db 4.4.20
> neon 0.26.3
> OpenSSL 0.9.8d 28 Sep 2006
> zlib 1.2.3
>
> I did try to update the files before committing, same result.
> I thought at first the problem is related to TortoiseSVN, but the
> same problem occurs no matter if I use TSVN or the command line.
>
> What am I doing wrong ?
>
>
> CU C>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Break your working copy in 3 easy steps
Posted by Matt Sickler <cr...@gmail.com>.
did you try `svn update` when that error happened?
On 2/18/07, CodeBase@web.de <Co...@web.de> wrote:
>
> Hi all,
>
> Assume there are 2 files in the repository which should always be
> committed together, such as an OpenOffice document and the PDF exported from
> it:
>
> /root/oo.org/mydoc.odt
> /root/pdf/mydoc.pdf
>
> Assume there are pending changes in the doc (exported to the PDF) worth
> committing.
>
> C:\> svn commit --message "some reasonable message"
> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf"
> --> OK
>
> Now create more changes and export them again. Repeat the step above.
>
> --> Modified: ...\mydoc.pdf
> Error: Commit failed (details follow):
> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
> Error: The version resource does not correspond to the resource within the
> transaction. Either the requested version resource is out of date (needs to
> be updated), or the requested version resource is newer than the transaction
> root (restart the commit).
>
> I read on the list about deleting wcprops files, but as I can't find any
> file of that name, the only way to get around the problem is to copy the
> changed file, remove the .svn folder and check it all out from scratch, then
> copy the changed file, again.
>
> Most recent SVN running on most recent Windows XP SP2
> Subversion 1.4.3,
> apr 0.9.12
> apr-iconv 0.9.7
> apr-utils 0.9.12
> berkeley db 4.4.20
> neon 0.26.3
> OpenSSL 0.9.8d 28 Sep 2006
> zlib 1.2.3
>
> I did try to update the files before committing, same result.
> I thought at first the problem is related to TortoiseSVN, but the same
> problem occurs no matter if I use TSVN or the command line.
>
> What am I doing wrong ?
>
>
> CU C>
>
> _______________________________________________________________________
> Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
> Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Break your working copy in 3 easy steps
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 2/19/2007 5:35 AM, CodeBase wrote:
> Ulrich Eckhardt schrieb:
>> On Sunday 18 February 2007 22:59, CodeBase@web.de wrote:
>>> Assume there are 2 files in the repository which should always be committed
>>> together, such as an OpenOffice document and the PDF exported from it:
>>>
>>> /root/oo.org/mydoc.odt
>>> /root/pdf/mydoc.pdf
>> Some people consider that flawed and that only the source data should be held
>> there. YMMV.
>>
>>> Assume there are pending changes in the doc (exported to the PDF) worth
>>> committing.
>> So there are changes in both files that should be committed, right? Subversion
>> doesn't care where those changes come from.
>>
>>> C:\> svn commit --message "some reasonable message"
>>> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf" --> OK
>>>
>>> Now create more changes and export them again. Repeat the step above.
>> Again, you changed both files.
>>
>>> --> Modified: ...\mydoc.pdf
>>> Error: Commit failed (details follow):
>>> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
>>> Error: The version resource does not correspond to the resource within the
>>> transaction. Either the requested version resource is out of date (needs to
>>> be updated), or the requested version resource is newer than the
>>> transaction root (restart the commit).
>> Hmmm, looks like someone else already checked in a changed version of the PDF,
>> though it's hard to tell from that message.
>>
>>> I read on the list about deleting wcprops files, but as I can't find any
>>> file of that name, the only way to get around the problem is to copy the
>>> changed file, remove the .svn folder and check it all out from scratch,
>>> then copy the changed file, again.
>> No, that shouldn't be necessary.
>>
>> Some theories:
>> 1. Something else is going on, and that is probably something you don't tell
>> us, probably something automated that modifies either your repository or
>> workingcopy.
>>
>> 2. Some tool is running amok and modifying the private metadata that belongs
>> to Subversion, e.g. some batch replace job that doesn't care about
>> write-protected files.
>>
>> In any case, it's not in what you're telling us but in what you're not telling
>> us.
>>
>> Uli
>>
>
> OK, forget about ODT and PDF, they were just meant to illustrate the
> problem.
> Assume 2 files, both are changed twice and should be checked in twice.
> The first time the check in works, the second time it fails.
>
> Noone besides me works on these files. Noone has checked in anything.
> Whenever I run into the issue, I try to update them without change.
> There are no automated tools running that modify anything.
>
> I can reproduce this problem in less than a minute.
>
> The only thing I've simplified for the sake of... well, simplicity is
> that the the file paths are longer and the files themselves are not
> actually called mydoc.odt or mydoc.pdf and my working copy does not
> reside in C:\SVNWC, but I think you guessed that anyway.
>
> Is there any debug level I can crank up ? Is there any other information
> I can provide that might help solving this ?
It would be helpful if you posted a script to reproduce the problem, so
others can see it too. Start with "svnadmin create testrepos", use
"echo mod1 >file1" kinds of instructions to create the files, etc.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Break your working copy in 3 easy steps
Posted by CodeBase <co...@web.de>.
Ulrich Eckhardt schrieb:
> On Sunday 18 February 2007 22:59, CodeBase@web.de wrote:
>> Assume there are 2 files in the repository which should always be committed
>> together, such as an OpenOffice document and the PDF exported from it:
>>
>> /root/oo.org/mydoc.odt
>> /root/pdf/mydoc.pdf
>
> Some people consider that flawed and that only the source data should be held
> there. YMMV.
>
>> Assume there are pending changes in the doc (exported to the PDF) worth
>> committing.
>
> So there are changes in both files that should be committed, right? Subversion
> doesn't care where those changes come from.
>
>> C:\> svn commit --message "some reasonable message"
>> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf" --> OK
>>
>> Now create more changes and export them again. Repeat the step above.
>
> Again, you changed both files.
>
>> --> Modified: ...\mydoc.pdf
>> Error: Commit failed (details follow):
>> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
>> Error: The version resource does not correspond to the resource within the
>> transaction. Either the requested version resource is out of date (needs to
>> be updated), or the requested version resource is newer than the
>> transaction root (restart the commit).
>
> Hmmm, looks like someone else already checked in a changed version of the PDF,
> though it's hard to tell from that message.
>
>> I read on the list about deleting wcprops files, but as I can't find any
>> file of that name, the only way to get around the problem is to copy the
>> changed file, remove the .svn folder and check it all out from scratch,
>> then copy the changed file, again.
>
> No, that shouldn't be necessary.
>
> Some theories:
> 1. Something else is going on, and that is probably something you don't tell
> us, probably something automated that modifies either your repository or
> workingcopy.
>
> 2. Some tool is running amok and modifying the private metadata that belongs
> to Subversion, e.g. some batch replace job that doesn't care about
> write-protected files.
>
> In any case, it's not in what you're telling us but in what you're not telling
> us.
>
> Uli
>
OK, forget about ODT and PDF, they were just meant to illustrate the
problem.
Assume 2 files, both are changed twice and should be checked in twice.
The first time the check in works, the second time it fails.
Noone besides me works on these files. Noone has checked in anything.
Whenever I run into the issue, I try to update them without change.
There are no automated tools running that modify anything.
I can reproduce this problem in less than a minute.
The only thing I've simplified for the sake of... well, simplicity is
that the the file paths are longer and the files themselves are not
actually called mydoc.odt or mydoc.pdf and my working copy does not
reside in C:\SVNWC, but I think you guessed that anyway.
Is there any debug level I can crank up ? Is there any other information
I can provide that might help solving this ?
TIA,
CU C>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Break your working copy in 3 easy steps
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Sunday 18 February 2007 22:59, CodeBase@web.de wrote:
> Assume there are 2 files in the repository which should always be committed
> together, such as an OpenOffice document and the PDF exported from it:
>
> /root/oo.org/mydoc.odt
> /root/pdf/mydoc.pdf
Some people consider that flawed and that only the source data should be held
there. YMMV.
> Assume there are pending changes in the doc (exported to the PDF) worth
> committing.
So there are changes in both files that should be committed, right? Subversion
doesn't care where those changes come from.
> C:\> svn commit --message "some reasonable message"
> "C:\SVNWC\oo.org\mydoc.odt" "C:\SVNWC\pdf\mydoc.pdf" --> OK
>
> Now create more changes and export them again. Repeat the step above.
Again, you changed both files.
>
> --> Modified: ...\mydoc.pdf
> Error: Commit failed (details follow):
> Error: Your file or directory ...\mydoc.pdf' is probably out-of-date
> Error: The version resource does not correspond to the resource within the
> transaction. Either the requested version resource is out of date (needs to
> be updated), or the requested version resource is newer than the
> transaction root (restart the commit).
Hmmm, looks like someone else already checked in a changed version of the PDF,
though it's hard to tell from that message.
> I read on the list about deleting wcprops files, but as I can't find any
> file of that name, the only way to get around the problem is to copy the
> changed file, remove the .svn folder and check it all out from scratch,
> then copy the changed file, again.
No, that shouldn't be necessary.
Some theories:
1. Something else is going on, and that is probably something you don't tell
us, probably something automated that modifies either your repository or
workingcopy.
2. Some tool is running amok and modifying the private metadata that belongs
to Subversion, e.g. some batch replace job that doesn't care about
write-protected files.
In any case, it's not in what you're telling us but in what you're not telling
us.
Uli
--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org