Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> Maybe this example was still too short to reveal the point of commitable
> tags. But imagine doing those operations on hundreds of files at the
> time. In that case it is mandatory that the operations you do, can be
> done easily, i.e all at once.
I am also not entirely sure I got your intention but some bits of what you
describe remind me of a potential problem I had to solve quite a while back.
I still haven't really solved it but ((un)fortunately) it also hasn't become
a real problem yet. Here's the scenario:
We have an app with reporting functionality supplied via a third-party
library. The individual report layouts are stored into separate files (text)
which get distributed along with the application. Some (but not all) of the
report layouts are customized for the individual customers (because of
different logos, corporate fonts, page margins, additional fields, etc.) and
some reports even exist for only one individual customer.
Currently I'm handling this with branches for each customer. We keep a set
of generic (non-customized) reports on the trunk and commit customisations
to the customer branches. Before we make a new release for a customer we
check out the report folder on his individual branch and take the files from
there.
The downside of this approach is that whenever I make changes to the generic
(i.e. non-customized) reports on the trunk I have to either merge those
changes to each individual branch (for those reports that are customized) or
move the customer branch tags to the new HEAD (for those without
customisations). I know that that last step is a bit of a dirty hack but
fact is that less than 10% of the reports are customized, the rest is
identical for all customers (and identical to the generic trunk reports). If
I always created branch revisions for those reports I would get a hell of a
lot of duplicated revisions. If I understood your request correctly, this
moving of the branch tag could happen automatically with your approach, no?
Unfortunately the file format used for those report layouts does neither
allow for inheritance nor for conditional processing (at least not without
significantly compromising runtime performance). Also, many of the
customisations we have to do do not merge awfully well, too (but that's
really a different matter of course).
As I said this hasn't turned into a real problem yet as the number of
customers and customisations is still quite small and we didn't have to
touch the existing reports a lot after the initial release but I think
anyone can easily imagine the management nightmare waiting to happen if
those numbers increase, which is exactly what we're expecting to happen in
the next few weeks at long last.
Apart from the request at hand which would IMO still be a cludge (if I did
interpret it correctly that is), could anyone think of a manageable
alternative approach to this scenario?
Cheers,
Oliver
---- ------------------
JID: ogiesen at jabber.org
ICQ: 18777742
(http://wwp.icq.com/18777742)