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

Re: fun with Unix command lines

From: Tom Lord <lord_at_regexps.com>
Date: 2002-07-23 03:40:58 CEST

   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

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?).


   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;
   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


   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

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.