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

Re: short question about merge [PROPOSAL] vs. tree-deltas

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-04-18 13:08:04 CEST

Tom Lord <lord@emf.net> writes:

> Mostly I left out explaining why "this won't work" to keep the message
> from being huger than huge.

You could try simply writing shorter emails.

I have only skimmed what you wrote but it appears that you are
describing a series of copy, move, modify and merge events. Why don't
you just write down those events

    - start with a file foo/bar at rev A
    - copy foo/bar at rev A to foo2/bar at rev B
    - modify foo2/bar to produce rev C
    - etc.

Make it easy for other people to read and understand. It takes you a
dozen lines to describe a single directory copy operation, and even
then the copy operation is buried in the prose. Why do you do that?
I know you like to think we are misguided, but do you really think
that we don't understand why someone would make a branch? Sentences
like

 "He wanted to work on these without messing up the current src/doc
  directory."

are superfluous. They serve only to hide the important information.
They take up your time writing them and our time reading them. Leave
them out. We don't need, or want, cute stories about translators,
writers and programmers.

I don't really want to ignore you, but until you start presenting
concise arguments the investment I need to put into reading your
emails is too high. You lose out because you get ignored. I lose out
if you have important ideas.

[Snip Tom's argument, it's obscured by far too many unnecessary words.]

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 18 13:08:55 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.