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