However, I've printed off the discussion on the arch-dev alias and will
be reading them either on the drive home, or tonight.
"Captain, they're returning our hail..."
Fantastic. (Please read my svn flames carefully, since I think that
will make it clear that they are not actually negative -- though they
aren't exactly an endorsement, either.)
From a purely technical perspective, I think our projects probably
have a lot to offer one another, once we get past the BS about which
one "wins" or gets to 1.0 first and other such garbage (maybe ask
Brian B., the first svn rep I contacted many months ago, about what
degree of asshole I am :-) Talk about getting off on the wrong
foot...).
My take: SCM is close enough to math that we don't have much room to
_make up_ a good design; we pretty much have to _derive_ a good design
from the underlying math. Basically, I think there's a lot more
precision to this field than most people assume and that our two designs
should ideally reflect both that precision, and a unity of
understanding of the logical structure of SCM problems. Lofty and
goofy sounding, I know --- unfashionably so --- yet....
Please let's continue the discussion tomorrow, then (off list?).
Regards,
-t
Mailing-List: contact dev-help@subversion.tigris.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <mailto:dev-help@subversion.tigris.org>
list-unsubscribe: <mailto:dev-unsubscribe@subversion.tigris.org>
list-post: <mailto:dev@subversion.tigris.org>
From: "Bill Tutt" <rassilon@lyra.org>
Cc: <dev@subversion.tigris.org>
Date: Mon, 22 Jul 2002 14:38:52 -0700
Content-Type: text/plain;
charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 22 Jul 2002 21:38:52.0114 (UTC) FILETIME=[2BFEE320:01C231C8]
X-UIDL: DL<"!Q!)!!SYX!!C)-!!
> From: Tom Lord [mailto:lord@regexps.com]
>
> * About patch set manipulation and formats
>
> gstein: I've been thinking about this one off and on for the
> past week. Some people have been desirous of moving
> patch sets around, and having a well-defined format
> to do all the work (tree changes, text changes, and
> prop changes) would be very nice.
>
> my reply:
>
> Do you agree with these design goals, if they are easily
> achieved?:
>
> *) new patch set formats should be SCM-system
> independent
>
> *) new patch generation and application tools
> should work both on SCM working trees,
> and on "ordinary" trees
>
> *) the new patch tools should handle exact and
> inexact patching that includes tree rearrangements
>
Agreeing on design goals is a little premature at present. The
subversion team is focused on getting their work done and out the door.
However, I've printed off the discussion on the arch-dev alias and will
be reading them either on the drive home, or tonight.
I do think we're more likely to agree about a format then on a specific
tool set.
[.....]
>
>
> * about atomicity
>
> gstein: Eh? Maybe I'm misunderstanding what you're saying,
> but we version things as atomic sets of changes.
>
> my reply:
>
> Nevermind. It's a subtle point and a tangential one -- not
> worth trying to explain in detail right now.
>
If I understood what you were trying to say you should check out the
latest structure of the Subversion filesystem. We now de-normalize all
of the files that were changed per repository revision.
i.e. it's very easy to go from Repository Revision ID to list of files
changed in that RevisionID.
If you meant attaching some other possible meaning to the change, then
clearly we haven't done that. i.e. patch levels, versions, etc...
>
>
>
> * about distributed revision control
>
>
> gstein: We haven't applied any real thought to this problem,
>
> [...] although I do know that many people are
> interested in adding new types of distribution to
> SVN. Our use of HTTP should actually be quite helpful
> here, since it is possible to have an HTTP proxy that
> aggregates multiple repositories.
>
> my reply:
>
> If you are cooperative, we should discuss that. A proxy
> is a poor solution to the problem, but arch offers
> a simpler solution that can be adopted by other systems.
>
I don't think now is the time to think about distributed revision
control for Subversion. We're simply too focused on getting 1.0 out the
door. However, Subversion's schema should be designed in such a way as
to make making it distributable fairly easily by extending keys
appropriately.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 03:37:53 2002