Greg Hudson wrote:
>> And yah... "theoretical" configurations could certainly want to
>> refer to an individual file, but ... blarg. Theoretical.
>
>
> We might even have a desire to support per-version configurations.
> Say we wanted our own branch of APR, without bothering the people who
> maintain the APR repository. Files and directories we've modified in
> the apr-subversion hierarchy would have a normal node for the head
> revision, but when you ascend the ancestor chain far enough you get a
> configuration node pointing into the apr repository.
>
> Yeah, this sounds really confusing at the implementation level, but at
> the UI level I think it just translates into capability were you'd
> normally expect it. Consider what happens when you have a regular
> directory configuration node for "apr" in the subversion repository
> and someone tries to branch it--if all we have is per-directory or
> per-dirent configurations, we'll have to fail out.
Hear, hear! And I know how to write a filesystem on top of that. Let me
tell you what fun it can be to implement move/rename. Did that for four
years, ran away and let others take over, and they still haven't got it
right.
Oops, got to go, those big guys in the white coats are after me again
... :-)
> (Incidentally, I'm not totally sold on the term "configuration." I
> don't think it's very intuitive. But I don't have a better term and
> Branko has been using it that way and the term seems to have some
> prior acceptance, so I'll use it in conversation for now.)
Basically, a configuration is a collection of versions (/not/ objects!)
in a CM system. It's a bit like a tag, except that it can change
dynamically. Guess where the term "Configuration Management" comes from? :-)
A change set is a similar, although less general concept, I think.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:16 2006