Keeping local configuration versioned

[Maciej Katafiasz]

Den Thu, 27 Nov 2008 14:54:42 +0200 skrev Marius Kruger:

> 2008/11/27 Maciej Katafiasz <mathrick at gmail.com>
>> To reiterate, the end effect I want to achieve is that I have two
>> branches: "mainline" and "devel". Devel is branched from mainline, and
>> synced regularly with it. Additionally, devel has two flavours of
>> changesets: actual development and local config adjustment. I want
>> commits to go to the development bag unless I explicitly state
>> otherwise, and I want to be able to push from devel to mainline at any
>> time and have _only_ the development changesets merged, without having
>> to remember to pull to/push from/exclude something, and ideally without
>> having to use something else than "bzr commit" for commits. I'm okay
>> with there being multiple branches internally, as long as it doesn't
>> require me to remember about the fact.
> I normally keep these sort of things in separate directories:
> myproject_main/.bzr
> myproject_conf/.bzr
> where each is versioned separately.
> As far as I know the one can even be inside the other eg: myproject/.bzr
>  +code/*
>  +conf/.bzr
> in this case the myproject branch would ignore conf completely. when you
> do want to commit stuff in conf you'll need to cd into it.

Right. That makes sense with the addition of nested branches in recent 
versions, and should even be doable (the conf files reside inside conf/) 
in my source. However, that's sort of hard to adapt to when I want to 
change the conf files _and_ have it visible upstream, or when the files 
are scattered/interleaved with regularly versioned files. Sadly, I can't 
exclude either possibility, as it's a huge PHP codebase with no prior 
history of proper maintenance (it has just seen the light of a VCS, there 
are still a million copies not versioned that might possibly need to have 
their changes integrated, and I know there'll be truckloads of 
refactoring/rewriting going on). Thus it might be too limited a solution. 
Not to mention that I'd like to see a proper way now I've actually had a 
chance to think the problem through and state it fully :). In any case, 
thanks for the suggestion.

Cheers,
Maciej