You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by André Pönitz <an...@wasy.de> on 2007/03/23 11:02:48 UTC
import --force?
Hi all.
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.
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.
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.
The 'ideal' solution would be some kind of '--force' flag
for svn import that would ignore that fact, but that does not
seem to be available (at least not wih 1.2.0)
So the question: Does anybody have an idea how to improve this
setup?
Andre'
PS: I could, of course, check out some working copy, copy the new
stuff over and run an ordinary commit, but that's not too nice either
as it occupies local storage that's not exactly needed.
I could also rsync the stuff to a wc checked out locally on the
server and commit from there (and I will probably do that if
no other idea crops up). Not too nice, either, even if the wc
on the server won't hurt that much...
--
André Pönitz, Software Developer
WASY GmbH, Institute for Water Resources Planning and System
Research, Waltersdorfer Straße 105, 12526 Berlin, Germany
Register Court: Amtsgericht Charlottenburg, HRB 36263
Management: H.-J. G. Diersch, S. Kaden, I. Michels
Phone: +49 30 67 99 98-0; Fax: +49 30 67 99 98-99
Web: www.wasy.de, E-Mail: andre@wasy.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: import --force?
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
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
Re: import --force?
Posted by Matt Sickler <cr...@gmail.com>.
sounds like someone is using a source code control system as a binary
distribution system.
svn is used to version source code, not give an easy way to distribute
compiled binaries or libraries
you wouldnt use a fork to eat soup now would you?
On 3/23/07, André Pönitz <an...@wasy.de> wrote:
>
>
>
> Hi all.
>
> 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.
>
> 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.
>
> 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.
>
> The 'ideal' solution would be some kind of '--force' flag
> for svn import that would ignore that fact, but that does not
> seem to be available (at least not wih 1.2.0)
>
> So the question: Does anybody have an idea how to improve this
> setup?
>
> Andre'
>
> PS: I could, of course, check out some working copy, copy the new
> stuff over and run an ordinary commit, but that's not too nice either
> as it occupies local storage that's not exactly needed.
>
> I could also rsync the stuff to a wc checked out locally on the
> server and commit from there (and I will probably do that if
> no other idea crops up). Not too nice, either, even if the wc
> on the server won't hurt that much...
>
> --
> André Pönitz, Software Developer
> WASY GmbH, Institute for Water Resources Planning and System
> Research, Waltersdorfer Straße 105, 12526 Berlin, Germany
> Register Court: Amtsgericht Charlottenburg, HRB 36263
> Management: H.-J. G. Diersch, S. Kaden, I. Michels
> Phone: +49 30 67 99 98-0; Fax: +49 30 67 99 98-99
> Web: www.wasy.de, E-Mail: andre@wasy.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>