[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Autodeploy with Subversion (merging giving me a headache)

From: Johnson, Rick <JohnsonR_at_gc.adventist.org>
Date: 2005-03-03 16:30:36 CET

Required info: Windows 2003, Subersion 1.1.1 (r11581), Apache 2.052,
Draco.Net 1.6.0, Nant .85

I have a repository set up like thus:


I check out a working copy of the Development directory and make my
changes. When I commit to the Development direcotory I have a process
set up to automatically compile and deploy (with Draco.Net and NAnt) to
my staging server. When I am ready to go live with a build I merge
changes from the Development directory to the Production directory. When
changes are committed to the Production directory the application is
autodeployed (via essentially the same process) to my production server.

(for those who don't know or haven't infered what's going on: Draco.Net
looks at a pre-defined "directory" in the repository at specified
intervals and when changes are made, starts a pre-defined process, in my
case, a NAnt build script)

I'm having a very difficult time with merge tracking and have shot
myself in the foot a couple of times. In my situation, I would much
rather use Tags in the Production directory since that's really what I'm
deploying. My problem is that I haven't figured out a way to have the
autodeployment work with a directory full of Tags rather than just the

Any suggestions would be helpful. I've thought of always having a
"Current" Tag and renaming it and creating a new "Current" tag when it's
time for a live build but that seems inelegant and doesn't impart any
date/time or version information. It would probably be more elegant that
what I've done to fix a screwed up merge though.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 3 16:35:14 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.