Re: import --force?

On Friday 23 March 2007 12:02, André Pönitz wrote:
> I am currently trying to build a repository consisting of
> 'redistributables' of several of our projects.
>
> The idea is that a couple of projects create 'something'
> (usually the stuff that's copied around on 'make install').
> This 'something' should be collected in an svn project,
> so that everybody can get said 'something' via 'svn export'
> without having to build it by himself.

So far, so good...

> I have a working solution for that, but that's Not Nice(tm).
> I use:
>
> #!/bin/bash
>
> BuildRoot=...
> Repo=https://svn/repository/x
>
> for i in \
> {x86,x64}/bin8/foo.dll \
> {x86,x64}/dbg8/food10.dll \
> include/foo.h
> do
> echo "Updating: $i"
> svn remove --non-interactive --quiet -m "Remove $i" "$Repo/$i"
> svn import --non-interactive --quiet -m "Update $i" "$BuildRoot/$i"
> "$Repo/$i" done
>
>
> I.e. for each file I wich to redistribute I run svn remove and
> svn import, so for n files I get 2*n svn revisions, which gets
> awful if I distribute a few hundred files.

That doesn't make much sense to me, normally, you would use a working copy for
that and commit all changes in a single revision. Also, that would give you
the means to first test the new version in that working copy.

Now, assuming you can get it to install into an arbitrary place (like with
autotools), you could use svn_load_dirs.pl to afterwards sync the state of
that place with the repository. It's documented in the SVN-book for tracking
vendor changes.

> An improvement would be to create a temporary directory linking
> in all the 'interesting' files and use svn import's recursive
> capabilities. However, that stll leaves the 'remove' step,
> which in turn seems to be needed as import refuses to overwrite
> an already existing file in the repo.

Import is for initially importing things. What you want is to add new files or
update/remove existing ones, not to import things all over!

> PS: I could, of course, check out some working copy, copy the new
> stuff over and run an ordinary commit,

Danger: this won't add new files or remove deceased ones! svn_load_dirs does
that...

> but that's not too nice either
> as it occupies local storage that's not exactly needed.

Then go an delete the working copy afterwards! Why is the place such a
problem? Disk space is cheap!

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