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

Re: Reality check [was: Re: merge tracking use cases]

From: Jay Levitt <lists-svndev_at_shopwatch.org>
Date: 2007-12-01 22:04:02 CET

> I'm just trying to point out that Subversion
> is trying to solve a much more complicated problem than the newer
> systems.

This may be a really dumb question:

Does the complicated problem need solving?

Importantly, that's a different question than "Do people use the
features that solve the complicated problem?" I'm asking if they still
*need* to stay solved - and whether they need to stay solved more than
other features need to *get* solved. I've never seen subtrees and
combined WCs in use, and in fact some popular tools (I think) don't even
support all the variations (Mark?).

And I'm asking it because I've recently had the opportunity to rethink a
project I did about fifteen years ago - a mail server that had some
unique characteristics, like the ability to instantly verify recipients
and then guarantee delivery. That wasn't even considered a feature; it
was simply the way it had to work, and you wouldn't think of changing it
any more than you'd think of changing the server to work without any
CPUs installed.

But that core aspect turned out to have huge implications for design.
Other systems were doing interesting things that just Weren't That
Simple for us. The others were, as you say, solving a different
problem. Once you understood our design, you understood why things had
to be the way they were, and it made perfect sense. It almost became a
rite of passage for new hires: They'd come in with all sorts of ideas
they wanted to implement, and one by one, we'd beat them down with The
Story of why it had to be this way, and why those other ideas didn't
work here.

Fifteen years later, nobody expects e-mail to be guaranteed deliverable.
   Nobody misses that it used to be that way. But everybody expects it
to do all sorts of other things that guaranteed delivery prevents - and,
therefore, nobody uses that mail system any more.

Subversion feels like it might have A Story of why it Has To Be That
Way... make sure it really does.

Jay Levitt

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 22:04:41 2007

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.