[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: what proofs look like

From: Tom Lord <lord_at_regexps.com>
Date: 2002-08-12 18:12:26 CEST

> A common patch set format would indeed be nice, but honestly
> it isn't going to be on the top of anybody's plate for
> awhile yet.

In my experience, if you set out to work on a common patch set format,
it changes (for the better, I think) how you see other important
aspects of revision control systems. It's just a conversation

If we work out a patch set format, that may well (in my opinion) lead
to (at least) slight (but significant) changes to your storage manager
and client side user interface.

The kinds of storage manager changes I (suspect) might be wanted for
svn are (from what I can tell so far -- more work is needed) of a sort
that will make converting old archives to the new format problematic.
In other words, I'm talking about semantic changes to your database --
not just representation changes.

Something else that came up more recently on this end is user

Most users of arch find arch's to be tedious and awkward in several
places and, in my experience, it makes it a little more difficult than
it ought to be to produce clean (single change) commits. So that has
to be fixed. A few have requested an essentially CVS-like front-end
to arch -- something closer to svn.

Well, I can see how that could be done (and, interestingly, it would
leave us with another gratuitous incompatibility problem, as far as I
can tell).

On the other hand, I think there's other approaches very different
from CVS that will ultimately be easier to learn and use and will make
it natural for developers to produce clean change sets. Very roughly:
I want to build a client-side "librarian" for working trees that makes
it easier for programmers to have *many* trees at once, do weird
mix-n-match on the fly for compiling and testing those trees, work on
each change in a separate tree and, thus, get clean change sets from
whole-tree commits. Again, very roughly: my _tentative opinion_ is
that this needs only a radically simplified revision control system
layer, but then some little tools on top of that to help programmers
manage all those trees without getting lost. Hopelessly vague, I
realize. Maybe it will make some sense to you. The only point is
that if you have a slightly different perspective on patch sets, I am
fairly certain it will have positive impact on your view of all other
aspects of the system.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 18:05:25 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.