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.
On Fri, May 3, 2013 at 11:44 AM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Fri, May 3, 2013 at 11:23 AM, C M <cmanalyst66_at_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. 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
> lesmikesell_at_gmail.com
>
Received on 2013-05-03 19:00:16 CEST