SVN Import command

800 views
Skip to first unread message

C M

unread,
May 3, 2013, 12:23:04 PM5/3/13
to Subversion
Hello,

We plan to use a SVN repository as a deployment mechanism so technicians can download and install the application binaries for a customer system.

The directory where we want them to download from will always have the "current" binaries.

The issue I am facing is how to replace (overwrite) the application binary in the directory when there's a new version of it.

I tried to use the "svn import" to overwrite but it doesn't seem to like that. I also tried it with the "svn import --force"


 svn: E150002: Path 'svn://X.XX.XXX.XX/' already exists

Is there another way to accomplish this?

Amad

Les Mikesell

unread,
May 3, 2013, 12:44:53 PM5/3/13
to C M, Subversion
Basically, after your initial import you want to delete or rename the
directory you imported and check it back out as a working copy. Then
to make changes you will overwrite the files in the working copy with
the new versions and 'svn commit' to update the repository. If you
add new files you must 'svn add' them before the commit (if it is
automated, you might 'svn add *' and ignore the error messages about
existing items). Depending on how 'visible' you want to make the
versioning, you might (or might not...) want to arrange the usual
/trunk, /branches, /tags layout for your files, always updating the
trunk copy and after each commit, copy it to a tag with your own
revision numbering scheme. Also, you might use something like viewvc
for web browser downloads and the ability to pick back-rev versions if
needed. Even without tagging, this will give you access to any
version you have committed.

--
Les Mikesell
lesmi...@gmail.com

Daniel Shahaf

unread,
May 3, 2013, 12:51:23 PM5/3/13
to Les Mikesell, C M, Subversion
Les Mikesell wrote on Fri, May 03, 2013 at 11:44:53 -0500:
> On Fri, May 3, 2013 at 11:23 AM, C M <cmana...@gmail.com> wrote:
> > We plan to use a SVN repository as a deployment mechanism so technicians can
> > download and install the application binaries for a customer system.
> >
> > The directory where we want them to download from will always have the
> > "current" binaries.
> >
> > The issue I am facing is how to replace (overwrite) the application binary
> > in the directory when there's a new version of it.
> >
> > I tried to use the "svn import" to overwrite but it doesn't seem to like
> > that. I also tried it with the "svn import --force"
> >
> >
> > svn: E150002: Path 'svn://X.XX.XXX.XX/' already exists
> >
> > Is there another way to accomplish this?
>
> Basically, after your initial import you want to delete or rename the
> directory you imported and check it back out as a working copy.

http://subversion.apache.org/faq#in-place-import

C M

unread,
May 3, 2013, 12:59:44 PM5/3/13
to Les Mikesell, Subversion
I don't understand why I can't simply over-write the existing file in the directory? On many occasions, a build may only result in one new executable. To have to delete/rename the entire directory seems like overkill.

And for the most part, we only have one top level directory below which all the executables are stored.


Thorsten Schöning

unread,
May 3, 2013, 1:09:25 PM5/3/13
to us...@subversion.apache.org
Guten Tag C M,
am Freitag, 3. Mai 2013 um 18:59 schrieben Sie:

> I don't understand why I can't simply over-write the existing file
> in the directory? On many occasions, a build may only result in one
> new executable. To have to delete/rename the entire directory seems like overkill.

Deletion/renaming was meant for the source of your data after initial
import to be able to checkout a working copy into the same directory,
e.g. your build target. You don't need to delete or rename after you
have checked out a working copy, just overwrite your files and commit
the changes.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Les Mikesell

unread,
May 3, 2013, 1:21:00 PM5/3/13
to C M, Subversion
On Fri, May 3, 2013 at 11:59 AM, C M <cmana...@gmail.com> wrote:
> I don't understand why I can't simply over-write the existing file in the
> directory? On many occasions, a build may only result in one new executable.
> To have to delete/rename the entire directory seems like overkill.

Converting the initial import directory from a non-working copy to an
svn working copy is a one-time thing. There are ways to work around
it if the executables are in-use or something that makes the rename
and checkout process a problem. The point is that to get the
versioned commits, you need to do it from an existing working copy.
You can keep re-using the same working copy for all subsequent
changes. The working copy holds a hidden 'pristine' copy of the
checked-out version, so subsequent commits know what differences to
send to the repository.

> And for the most part, we only have one top level directory below which all
> the executables are stored.

You don't have to add the /trunk, /branchs, /tags layout if it doesn't
make sense for your usage. Subversion just treats them as arbitrary
names, but by convention they can be used to give 'human friendly'
names to specific revisions. Normally the point of using a version
control system is that you have access to older versions that have
been committed and the tags just give you an easier way to find them
than knowing the repository revision number.

--
Les Mikesell
lesmi...@gmail.com

kmr...@rockwellcollins.com

unread,
May 3, 2013, 1:43:39 PM5/3/13
to Les Mikesell, C M, Subversion
> I don't understand why I can't simply over-write the existing file in the
> directory? On many occasions, a build may only result in one new executable.
> To have to delete/rename the entire directory seems like overkill.

While it kinda defeats the purpose of Subversion, you can use the svnmucc
utility to "overwrite" an existing file, even with the same contents:

svnmucc put test.txt http://server/kmr_test/trunk/foo/test.txt -m"Add file"
r479 committed by kmradke at 2013-05-03T17:36:00.823078Z

svnmucc put test.txt http://server/kmr_test/trunk/foo/test.txt -m"Overwrite file"

svn log http://server/kmr_test/trunk/foo/test.txt
------------------------------------------------------------------------
r480 | kmradke | 2013-05-03 12:36:12 -0500 (Fri, 03 May 2013) | 1 line

Overwrite file
------------------------------------------------------------------------
r479 | kmradke | 2013-05-03 12:36:00 -0500 (Fri, 03 May 2013) | 1 line

Add file
------------------------------------------------------------------------

svn diff -r479:480 http://server/kmr_test/trunk/foo/test.txt


In this case no local working copy is needed, but it will happily
let you overwrite the file with the same contents and create create
a new subversion revision.  Note that the complete file contents
will be sent to the server each time.

If you are on Windows I'm not sure what distributions include svnmucc.
(TortoiseSVN does not)

Kevin R.

C M

unread,
May 3, 2013, 2:03:42 PM5/3/13
to kmr...@rockwellcollins.com, Les Mikesell, Subversion
This is precisely what we are looking for. For the most part, we distribute a new executable for each update, so an overwrite is all we care about.

The main reason we are moving to SVN is because the current deployment process uses a fileshare where updates are pushed out to. At least with SVN, we'll have some traceability.


Thank you to everyone for your input.
Amad.
Reply all
Reply to author
Forward
0 new messages