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

Re: How best to delete a quantity of unwanted content from a directory that has been built automatically?

From: Mark Knoop <mark_at_rawcane.net>
Date: Fri, 1 Feb 2008 15:17:38 -0000

> On Feb 1, 2008 9:34 AM, Mark Knoop <mark_at_rawcane.net> wrote:
>> > Mark Knoop wrote:
>> >> Hi
>> >>
>> >> Say I have a directory under version control but the content of that
>> >> directory is generated from a script. Some files may be the same from
>> >> one
>> >> version to the next, some may disappear and new ones will be included.
>> >
>> > In practice, generated files should not be saved to the repository. By
>> > all means, save the script that generates the files, but by putting the
>> > autogenerated files under version control, you are going to create a
>> > lot
>> > of work for yourself (when the selection of files changes) and
>> > repository
>> > churn (when only the contents change).
>> >
>> > It sounds like you need a better build system (so that you always
>> > generate
>> > the "correct" files at any given time)...
>> >
>> > John
>> >
>> I was hoping I could use subversion to quickly return a production
>> environment (inc. code, resources, media etc) to a previous state but
>> will
>> need to rethink I guess.
>
> Is your "release to production" a scripted process, or do you manually
> move things? If it'ss scripted, this content generation could/should
> be integrated into it.
>

My workflow is something like this:

1) Generate production site to dev server
2) Test
3) Update live server
4) Make required changes to production site on dev server
5) Test
6) Update live server
7) Make changes to site generator code to implement the changes already
implemented to the site so the site can be regenerated automatically and so
new sites will have access to the same features
8) Generate production site to dev server
9) Test
etc

This works well in that it is quick and flexible and safe but keeping track
of the versions and being able to roll back can be a bit tricky which is why
I was hoping Subversion would help me out.

Sometimes 4) might even be replaced by making changes on the live server
which - although the popular consensus is that it is totally bad and wrong
and should never happen - in practice can be quite useful if one needs to
implement something quickly and it is too time-consuming or complex to
recreate the supporting scenario on the dev server - if my production site
is actually a working copy then at least I can commit any quick fixes I
implement so that I can keep my dev version in sync or roll back if I screw
up.

As well as keeping the site generating code in subversion (which is fairly
straightforward although it is not compiled and therefore the dev/test/live
environments are all the same) I would also like to keep the sites
themselves in subversion as I may have implemented a change directly to the
site after it was generated and I may want to return a site to a previous
version while I sort out something on the site generator.

It seems subversion is kinda tied around the idea of application source
code which is built and installed rather than code and content on a live
system... but I'll be happy if someone can show me otherwise.

Cheers

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-01 16:18:07 CET

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.