On Fri, Jul 19, 2002 at 12:02:51PM -0700, Tom Lord wrote:
>...
> namespace for lines of development. It's looking quite possible that
> we'll switch to using just (nearly) arbitrary paths, which means that
> svn and arch will have pretty much isomorphic namespaces. Make of
> that what you will.
Neat!
>...
> 1) whole tree patch semantics
>
> I believe there remain some annoying differences in how we
> handle inexact, tree-rearranging patches that could,
> perhaps, be smoothed over. Defining exchangable patch set
> formats is a subset of this problem.
I've been thinking about this one off and on for the past week. Some people
have been desirous of moving patch sets around, and having a well-defined
format to do all the work (tree changes, text changes, and prop changes)
would be very nice.
> 2) transaction granularity
>
> svn versions files one by one, arch versions them in
Eh? Maybe I'm misunderstanding what you're saying, but we version things as
atomic sets of changes. You can make 10 file changes, add three files,
delete one, shift a directory, and make property changes to 20 items, and
commit that as a single unit.
>...
> 3) distribution
>
> The arch server protocol handles distributed repositories.
> I see no a priori obstacle to a simple translator that can
> translate between arch server operations and operations on
> a local svn repository. Thus, we'd have more or less a
> layering of a distribution protocol on top of centralized
> servers. Lots of pesky details, though, I'm sure.
We haven't applied any real thought to this problem, although I do know that
many people are interested in adding new types of distribution to SVN. Our
use of HTTP should actually be quite helpful here, since it is possible to
have an HTTP proxy that aggregates multiple repositories.
>...
> Meanwhile, I think SCM has now pulled far out ahead of the IDE tools
> Real Programmers actually use in Real Life. Your recent bump up
Quite true. However, I'm not that concerned here. Once we actually ship an
alpha/beta/final, then I think the IDE guys will start to incorporate SVN.
Since we're library-based, and have bindings to multiple languages, I don't
think there will be a large hurdle for IDE developers to integrate SVN.
As a meta-comment: are today's IDEs capable of solid SCM management? Not at
all. For the most part, they're working with crap tools like CVS. The "real"
SCM tools are all closed source, so it makes integration with them very
difficult. I see SVN as a great basis for people to experiment with new
kinds of SCM features in the IDEs. We provide them with a good (open) basis
for building Cool Stuff(tm).
>...
> Is this making any sense to you folks are am I just wasting my
> breath?
Sure is, and never. While this list isn't necessarily for touting other
version control systems, I *do* believe that comparisons and contrasts to
them is very valuable for our own work. But also to a point: some
discussions in the past have gone way out into esoteric academic discussions
of SCM theory that just don't really apply to our mission of releasing a 1.0
product that can displace CVS.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 19 21:56:21 2002