[cvsnt] Feature request: Commitable tags

[Tuomas Huhtanen]

Oliver Giesen wrote:
> 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?

Sort of. The branch tags would not move anywhere, but the pointer tags 
"on top" of them would. So in your case, you wouldn't have a branch for 
each customer, but this writable tag. Only when you get some customized 
files, you would create branch for those individual files.

But as Tony suggested, the -f might work for you in this case. The only 
thing is that once you have checked it out with some branch, it stays 
there unless you take a clean checkout again. So if for example you have 
  created a branched document, check it out, then later modify the main 
document so that there is no need for the branch doc, the -f scheme 
would not work. The writable tag would recover that situation just fine.

One other situation where the -f would not be sufficient is that if you 
need multiple levels of branches. Again, the writable tags would handle 
that without a problem.

Tuomas

> 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)
>