resolving obstructions

["Miller, Eric" <Er...@amd.com>]

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

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.

How can I resolve this with svn commands and avoid temp files?
I know you can fake it by using a clean .svn file from an update:

mv test test_obs
svn up test
mv test/.svn test_obs
rm -rf test
mv test_obs test
(delete missing, add unversioned)
svn ci -m 'ugh' test

I don't like this especially because of the need to do a full update
just to get the .svn dir.

Is there a better way?

Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: resolving obstructions

[Ryan Schmidt <su...@ryandesign.com>]

On Feb 23, 2007, at 11: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
>
> 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.
>
> How can I resolve this with svn commands and avoid temp files?
> I know you can fake it by using a clean .svn file from an update:
>
> mv test test_obs
> svn up test
> mv test/.svn test_obs
> rm -rf test
> mv test_obs test
> (delete missing, add unversioned)
> svn ci -m 'ugh' test
>
> I don't like this especially because of the need to do a full update
> just to get the .svn dir.
>
> Is there a better way?

If Subversion implemented this enhancement, then you could declare  
the directory as opaque, and Subversion would not write into it:

http://subversion.tigris.org/issues/show_bug.cgi?id=707

But alas, it is not implemented.



-- 

To reply to the mailing list, please use your mailer's Reply To All  
function


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: resolving obstructions

[Ulrich Eckhardt <ec...@satorlaser.com>]

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