Re: gcc source management requirements

       One of the (unstated?) goals in Subversion was to keep the
       server's semantics very simple, and push as much as possible
       into the clients.

Very close to that idea, and, imo a better idea, is to not only keep
the server semantics simple, but also to make a very simple client
(both interactive and, in multiple ways, programmatic). Then strictly
layer the "CVS replacement" UI (whatever that means) over that.

That way you can develop a nice, clean semantics for "versioned file
system with cheap tree cloning", and then develop a source mgt tool
over that without succumbing to the temptation to pollute the file
system semantics in the name of expediency.

I suspect, not being totally familiar with your current code but
having read discussions here and at least some of your code/design
docs, that you already do have some layering along these lines -- but
it seems to me that:

        (a) A CLI for "just the filesystem" is highly desirable.

        (b) A spec document of the semantics of "just the filesystem"
            is highly desirable.

        (c) In recent design discussions, you tend to violate this
            layering, as for example when you consider solving source
            mgt problems by changing the semantics of file properties.

To further clarify: a nice CLI for "versioned file system...", would,
I suspect, have no such concept as a working directory. Working
directories would come in the layer above.

When I say that a filesystem spec and CLI is "highly desirable", I
mean at least two things: (1) it will likely have other applications;
(2) that layering discipline will improve your "cvs replacement"
design by giving it a more solid, less arbitrary foundation.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 14 07:18:06 2002