monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: [HACKERS] SCMS question


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: [HACKERS] SCMS question
Date: Fri, 23 Feb 2007 10:30:32 +1100
User-agent: Mutt/1.5.13 (2006-08-11)

> > >One thing that Monotone doesn't do to which we are used to, is
> > >$Id$-style keyword expansion. 
> > 
> > Monotone will never support such templating because it relies on SHA  
> > hashing to track the repo history, so changing the repo before the  
> > hashing would mean that monotone would have to track pre- and post- 
> > templated files.

Never say never.

We presently don't have such a mechanism as a first class component,
though it comes up as a feature request from time to time, and has a
number of legitimate uses. 

(It's also not *as big* an issue as some people have come to expect
from other VCSes - the use cases where you really want such a thing
are rarer, but they still exist.  Partial updates and mismatching
checkouts don't really happen since we handle divergence in better
ways, but files can still become detached from the tree and used
elsewhere, for example.)

We see this as another of a class of transformations on file content
that might be performed between the workspace and the "canonical"
database form.  Other variations on this theme include
platform-specific newlines, i18n character-set representations, and
others -- up to and including code reindentation to a "project style",
at least in some people's worldview.

We had some limited special cases to handle some of this (eg,
newlines) but they weren't very nice. Certainly, we avoided and
resisted adding any more awkward special cases for some of these other
wishes.  We now also have much much nicer attribute handling than we
used to when those were written; then, part of the problem we tried to
resist was the complexity of marking which files should/should not get
transformed.

A well-designed, more general system of "content transformation filter
hooks", perhaps keyed by mime-type and other attributes on the files,
would be a worthy and welcome replacement.  As long as the user
responsibility to arrange for the filters to be reversible is met, so
the transformation to workspace form and back again produces the same
hash, monotone won't care.

This would be a nice little side project for someone to contribute
when they feel a strong need and motivation to do so.

--
Dan.

Attachment: pgpBAzv9zk2t_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]