[Yanel-dev] Moving configuration files, css, xslt, etc. from SVN into testing and production

[Michael Wechner]

On 1/24/11 9:52 AM, Cedric Staub wrote:
> Hello there!
>
> On Thu, Jan 20, 2011 at 11:05:54PM +0100, Michael Wechner wrote:
>> Another way might be to have a registry of such files, which then could
>> be used to update these files automatically.
> It makes sense to have clear guidelines/procedures for moving data from
> one instance to another, but I'm not sure this should be part of Yanel.
> In my opinion it makes more sense for people to decide for themselves
> how to handle this problem and integrate it into their workflow.

well, I think we should at least provide some best practice ;-)

> Personally, I'm a big fan of distributed version control systems like
> Mercurial. All you'd have to do is to setup a Mercurial repository with
> three branches - devel, staging, production. Mercurial then allows you
> to push/pull/merge commits between the three branches.
>
> For example, say you are currently developing a new resource for a
> customer on top of the devel branch. Once done, you would simply "pull"
> a given commit or a specific set of changes into the staging and later
> the production branch, leaving everything else untouched.

well, the problem I see with this is the amount of data. For example if 
one has a huge amount of data within the data repository, whereas the 
developer only changed a CSS or Javascript, then you don't want to
"pull" all the other data across the network.

Another problem we are dealing with is testing versus productive 
configuration, e.g. email notification adresses.
> In my opinion that is a very neat solution to this problem :-). And on
> top of everthing, it makes everything version-controlled, so you can
> rollback to an older version in practically no time if anything goes
> wrong. Of course Subversion let's you do that too, but Subversion
> doesn't have branches, Subversion is centralized and not distributed,
> Subversion doesn't let you pull/push commits from repositories, etc.

we actually use SVN for some of our customers, but I think understand 
what you
are saying ;-)
> And even if you're currently using Subversion for development, you can
> just create a separate Mercurial repository for your content. Or you can
> create a Mercurial/SVN hybrid repository. You can even use Mercurial as
> a frontend for Subversion repositories! [1]
>
> [1] http://mercurial.selenic.com/wiki/WorkingWithSubversion
>
> Well I hope this email doesn't sound too much like an advertisement ;-).
> Just to be clear, other distributed version control systems like Git or
> Darcs also solve all of these problems. I just happen to like Mercurial.

no worries, I also think Mercurial has some great pros and it's good to hear
every opinion on this. Let me digest ;-)

Thanks

Michael

> Cheers :-)
> Cedric