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

Re: svn_client_patch()

From: Tom Lord <lord_at_emf.net>
Date: 2003-04-06 08:21:10 CEST

        As Karl says, someday when 'svn diff' is able to produce a
        "next generation" patch format that describes tree changes,
        then it makes sense to have 'svn patch' which interprets the
        new format as well.

        - Ben, who is waiting for Tom Lord to start a project to
          define said format. :-)

Tom Lord is eager (at least as far as these things go) to work on said
project and has a considerable start on it in the form of arch's
mkpatch which has yielded both a (strong) straw-man candidate, and a
variety of useful experience regarding that straw-man, both positive
and negative. He concedes that, minimally, the mkpatch format should
be serialized in a human-readable form (for most purposes), and he
would wish to gently remind you that such a format ultimately has some
implications throughout revision control, and that it would make sense
to "some day" work out those implications in the context of
subversion. He has, for roughly a year now, advertised and sought
support for undertaking such a project with the resources and
seriousness it deserves.

But when he isn't busy talking in the third person about himself, Tom
is currently rather distracted by the kind of financial emergency that
results from being unemployed for two years, after experiencing some
other disasters, all of which has not only eaten his modest savings,
but most recently left him quite significantly behind on all bills and
without budget for more than a few days more of food (never mind
electricity, water, connectivity and so forth). So, while Tom
believes he has quite a bit to contribute to the design and
implementation of revision control systems and source management
technology generally (not to mention some software projects in other
domains), he is rather frustrated by the rather ironic circumstance
that more than a year after the release of the first self-hosting
version of arch, when he is finally getting some pretty interesting
and encouraging uptake on the matter, it may very well be far too late
to do much more than hope to find an unoccupied, warm, subway grate in
some city more hospitable to the homeless than San Francisco. He
shudders to think that at this late stage, even a conventional
employment arrangement would postpone his financial recovery for a
considerable period -- an important consideration at his advanced age
of thirty-seven.

While he may have been somewhat ... er ... "flamboyant" in his
professional youth, and may have landed quite by chance in some rather
dysfunctional career situations, no doubt facts which contribute
substantially to his current unemployment, in the past few years at
least, he has generally despised the seeming necessity of public drama
regarding his circumstance -- at least to the extent, I can tell you,
that he does not exaggerate it. A drowning man generally lacks the
options either to dissemble, or keep his voice down. The author's
understanding, gentle reader, is that Tom mentions some details of
this circumstance only because he sees few options to repair the
situation himself, and calls upon his fellow hackers throughout our
industry to help hack the situation, in all of its multi-faceted
aspects.

If Tom were speaking directly, I think he would want to close this
note by acknowledging and expressing gratitude for those individuals
who have staved off the subway-grate option for the past couple of
months with their generous, personal, financial contributions -- they
have kept him in chicken wings and home-made pizzas and curries along
with the occasional fiscally irresponsible beer -- and they have,
above all, helped to keep him from completely giving up hope.

Back to the topic:

   2. Conflict markers!! Regular 'patch' will just crap out on
       conflicting hunks -- this behavior is poo. 'svn patch' could
       behave just like 'svn merge', except from a stream source
       instead of a repository. :-) Now tell me that isn't Goodness!

Whether conflict markers are goodness or not depends heavily on the
nature and functionality of adjacent tools. There are good reasons
to think that neither patch-style .rej files or merge-style conflict
markers are quite the right thing. It's an interesting area to visit
with a fresh perspective.

"You will save me, or I shall drown." -- A generation of (mostly) dead
English teachers everywhere, stressing the importance of "proper"
grammar when in a pinch.
-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 6 08:12:32 2003

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.