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

Re: resolving obstructions

From: Ulrich Eckhardt <eckhardt_at_satorlaser.com>
Date: 2007-02-26 12:23:51 CET

On Friday 23 February 2007 18:01, Miller, Eric wrote:
> Can anyone tell me how to resolve the following scenario:
>
> -Setup the test:
> svn mkdir test
> touch test/afile
> svn add test
> svn ci -m 'testing'
>
> -Create an obstruction here:
> rm -rf test
> mkdir test
> touch test/bfile
>
> -See the obstruction:
> svn status
> ~ test

Okay, just for the record, you should not have used rm on a versioned
directory. In fact I think you have to use the 'f' to force rm to delete the
write-protected .svn dir and thus clearly stated "Discard all security
measures, I know what I'm doing!".

> What I want to do is check in the new test/ as a revision of the old
> test/.
> The rm, mkdir, and touch commands approximate a 3rd party application
> that removes and generates data with non-svn commands.

Okay, that probably means that you have little influence on what this external
application does.

> How can I resolve this with svn commands and avoid temp files?

First option should be to tell the external tool not to touch files (in
particular the write-protected content of .svn) it doesn't know about.
However, it might also be the other way 'round that Subversion should not try
to version the contents of that directory. It depends. Unconditionally
removing write-protected content is a bug in that external application
though.

Then, an option is to not store generated files in the first place. Some
people frown upon that, exactly because it should be possible to regenerate
the content from the existing sources. I have a partial opinion on that and
actually check in released binaries. I don't care for diffing those though,
so I only make the tags and then add the binaries to the tags.

A third option is to work around it. You could e.g. automate the manual
workaround you described or you could generate the files into a different
directory instead and then copy/link them over in another build step.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Ronald Boers       Steuernummer: 02/892/02900 
Amtsgericht Hamburg HR B62 932      USt-Id.Nr.: DE183047360
**************************************************************************************
           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
Received on Mon Feb 26 12:24:22 2007

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.