monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: Keyword substitution?


From: Bruce Stephens
Subject: [Monotone-devel] Re: Keyword substitution?
Date: Fri, 05 Aug 2005 18:21:56 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Nuno Lucas <address@hidden> writes:

[...]

> What about a middle term solution, like having a "release" (probably
> another name) command, that would do the same as a checkout but with
> keyword substitution and no MT/ directory creation?

Like CVS's export, I guess?

Well, yes, but that's more or less where we came in, I think.

Maybe that would be worthwhile, but people can already do that if they
want (just by having some release or export procedure, say "make
export" which does whatever's appropriate).

What's appropriate depends almost entirely on what you're going to do
with these keywords, and I don't have a good feeling for what people
want them for.

It seems entirely possible to me that keywords come from RCS (or
perhaps some other contemporary system from which RCS took them), CVS
had them because RCS did (and they're still useful in CVS, mostly
because revisions are per file, I suspect), and Subversion has them
because CVS does, and the developers didn't want people to reject it
just because it lacked keywords.

Maybe there's still a place for keywords, but I can't think of a
convincing one as yet.


I find it more curious that (as far as I can tell) none of the modern
systems support per-file change logs.  (I seem to remember monotone
did have suitable certs that could be attached to files, but I'm not
sure they're still there, and there seems nothing particularly to help
with them.)

I'm guessing that people just don't find the need for them.  It's
caused some resistance at work to changing to anything else, since our
process includes per-file change logs (as well as per-changeset
descriptions---we have hacky scripts around CVS to do this), so we've
got a large repository full of files with such commentary (as well as
separate files listing per changeset comentary), and people don't want
to throw that away.

[...]





reply via email to

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