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

Re: general replies, last in thread?

From: Tom Lord <lord_at_regexps.com>
Date: 2002-02-06 13:17:43 CET

       However, I believe its one serious disadvantage is integration
       with applications. To create clients, custom tools, etc, those
       programs will need to spawn arch tools and talk via a
       pipe. Obviously doable, but I prefer linking to libraries and
       staying in a single process space.

1. Why that preference? That would seem to be an unjustified
   prejudice.

   Performance? Feh -- that isn't where the bottlenecks are.

   Ease of programming? Feh^2 -- large classes of bugs are avoided
   by using processes; at worst it's six of one, half dozen of
   another.

   Really, multi-process applications are a large part of the reason
   we use operating systems with processes at all.
 

2. If you insist, the arch repostiory, revision library, notifier,
   browser, and project tree structures are certainly amenable to
   single-process tools. Because arch is so small, and built around a
   kernel of very straightforward basis operations, it can be
   reimplemented as C libraries, a perl app, a ruby app, a scheme app,
   an ml app .. whatever. If you want to write apps which are
   extensions, arch is the simpler foundation.

     Euh... I think we aren't worried about the semantics. That's been quite
     well-defined for a while (branches are just other directories, so merging is
     just applying diffs from those paths against the working copy). We're
     working through the implementation and code (re)factoring.

That's oversimplifying the problem. The question of what diffs to
apply to what trees to accomplish a merge is non-trivial, particularly
in the case of branches which repeatedly merge back and forth from a
trunk, or trunks which repeatedly synchronize.

Yes, I agree that SVN has a plausible set of primitive concepts
(though there's some tweaks I'd make) -- but looking at the
documentation and merging plans recently posted to this list, I don't
see a high level solution, yet.

> Sorry -- one more complaint about svn's use of WebDAV: I don't think
> WebDAV has the right semantic model for programming. Sure, it let's
> you think about revisions to documents -- but revisions to source
> trees have a lot more structure than that.

    Euh... I think you have a bit to learn about WebDAV. In particular, check
    out Workspaces, Baselines, and Activity Sets. Those concepts all deal with
    entire sets of changes, manipulating them, merging them together, etc.

What of distributions? Multi-package configurations? ChangeLogs?
Surely a revision control system browser for programmers should relate
those pieces. Looking towards the future, what of bug database
synchronization? It is true that I am not a WebDAV expert, but am I
wrong in believing that it was not designed for software management,
but rather for a less specific space of revisioned documents?

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006

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.