> 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
Received on Mon Jul 22 23:39:25 2002