> We don't currently have releases... we have a large application which serves
> several clients (An ASP). We make changes to individual client's code as
> well as to the shared code. We make changes and deployments daily. I'm not
> sure if we can copy it into a tag everytime we make a change...
A SVN copy is generally cheap in terms of time and disk space, so it's
more of a procedural thing. Without tagging, how do you know what code
is deployed for who and why? Sounds like you're begging for an Ant
script! :)
Seriously, if you can tag the "release", whether it's full-fledged or
a bugfix (which you can lable with the bug tracking number, as
mentioned earlier in this thread), you can then just end up with
something like "ant deploytag rel-1.0.200060314085000" or whatever.
> > You can automate all of this with Ant scripts, or more sophisticated
> > apps like CruiseControl for continuous build on the
> > development/integration side
>
> This would be nice... but the problem I have with export is that it
> downloads all the code instead of just updating the files that have changed.
You can control SVN export on a much more granular level, depending on
your code structure. Let's say you've got this sort of layout
myapp
cfstuff
www
images
css
You can deploy *just* the cfstuff, or any subdirectory. Another
alternative is generating patch files, which have only the changes
between source and target.
Of course that assumes a lot about your directory structures and how
your deployment process works.
>
> Also our codebase is about 20k files (including subversion files), so it's
> probably about half that. My guess is that it will take quite a while to
> export that. This is not even counting the media files.
Agreed. But anything automated gives you a lot of control. If
feasible, you can export to a new directory, do any configuration, and
restart your CF app all in an Ant script -- which also gives you the
capability to roll back to the existing app if that's a desire.
> Also when you check out things you can see if anyone's made any changes to
> production directly (Which happens sometimes, and needs to be dealt with).
> If we're exporting things it won't even be possible.
That's true -- ironically, it solves your problems. A few times with
those direct-to-production changes being wiped out, the programmers
learn the lesson :)
> In the perfect scenario, we would have something like this:
>
> All the changes to dev are done through webdav or something and are stored
> in a dev repository.
>
> Once changes have been tested on dev, they are committed into a staging
> repository and the changes are updated on the staging server.
>
> Once it has passed QA, it is checked in from staging into the production
> repository and then updated on production.
>
> As far as I know though, there is no way to have a working copy tied to more
> then one repository (or branch) at the same time.
Weeeellllll..... you can tie individual directories to different
revisions/repositories/etc, but that can get *really* confusing really
fast. You can however use svn:externals on a properly structured
repository to handle different sets of code.
One of my clients has one core "application" that's customized for N
clients where in is <10. The bulk of the customization is in
configuration and media/text. Using a pretty conventional MVC Fusebox
structure, the main "application" is the model and controller with a
default set of view elements. Each customized app is it's own set of
view and configuration components and the rest of the application is
brought in using the externals to link to the main code. That way, all
the functional code stays in one place (much more maintainable for us)
while the client-specific code is managed on it's own. This prevents
splintering the core part of the app into 10 versions (one per client)
that then start to diverge.
> > It's very common. I'd run out and et Pragmatic Version Control with
> > Subversion and possibly Pragmatic Project Automation, both from the
> > Pragmatic Bookshelf. The SVN books is especially relevant here.
> >
>
> Thanks John, I will check those books out.
They are *really* good. And of course the free SVN book
(http://svnbook.red-bean.com/) is good too -- but the Prag books are
very practical and developer focused. Having done this a number of
times though, I find the hardest thing is changing established habits
about code control rather than any tech chanllenges.
--
John Paul Ashenfelter
CTO/Transitionpoint
(blog) http://www.ashenfelter.com
(email) [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235526
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
