Tom Lord said:
>A global namespace should be orthogonal to storage. It should assign
>names to tree states in a referentially transparent, global way,
>independent of anyone's particular software tool product. That
>facilitiates much, if you stop to think about it.
Of course it should be and it facilitates a great deal. I'm saying it
isn't *necessary*, which it isn't. I'm also saying that it corresponds
to major architectural change for Subversion, which isn't going to happen
between "Alpha" and "Beta". Of course, names of this sort could be attached to
the repository as an afterthought, but this is pretty much as much work
as a redesign.
I said:
> This is an interesting choice. I submit that Subversion
> should go in the other direction and make the framework for
> changeset manipulation integrally tied up with the "SVN
> filesystem".
Tom said:
>Why exactly? So that nobody can use your changesets unless they
>install svn?
Well, at the moment nobody can use Arch's changesets unless they install
arch. Heh.
My reason is that it doesn't require major redesign.
Adding an abstraction layer (to a tool designed without one, like
Subversion) is major redesign. Good redesign, almost always, but more of
a pain in the neck than rewriting from scratch.
Changesets can be exported and imported from/to any desired format,
anyway. The sort of changesets you want may depend on a
platform-indepenent naming scheme, of course.
Tom said:
>Increasingly, I get the impression that "replace CVS" is
>dev-list-speak for do-whatever-the-hell-is-most-convenient-for-us.
Not exactly. I'd say that the hidden meaning in "replace CVS"
is "get this usable as a replacement for CVS as damn quickly as
possible".
I said:
> But Subversion isn't designed as a changeset tool,
Tom Lord said:
>No, but elements of it are useful in that context. I think it would
Hah! What elements? The fast binary diffing format, OK, I'll give you
that.
>be productive for the core developers to consider what it would take
>to use svn as a changeset tool.
Probably would be useful. But this is what I'd say is necessary:
Redesign of the SVN repository filesystem to treat changesets as
primary and revisions as secondary. Rewrite of all the code dealing
with the repository to deal with that.
Is that gonna happen anytime soon? Seriously, now! If it *is*, then I
take back the following statement, and most of the rest of what I said!
I said:
> and it's never gonna be one;
Tom said:
>Then you are willfully ignoring the _real_ source mgt. problems that
>arise in modern software development.
Nope. I'm referring to the above comments: the architecture isn't going
to get redesigned in the near future (maybe it will be for "Subversion
2.0") because people want to get Subversion 1.0 out reasonably soon.
And such a change cannot be added in a sensible manner as an
afterthought; it requires a redesign. (Which is precisely what *you*
have been saying.)
Some other program (a future version of 'arch'? Subversion 2.0 in the
year 2006?) will be the Changeset tool people move to in the deep
future. Subversion will be the tool CVS users move to first, because
it will hopefully be production-ready in 2003 and will be nearly
command-equivalent.
I said:
> I think there's a way to handle this...
And contrary to the dismissive comments I've gotten, there is a way to
handle simple branching and merging schemes with very little work, namely
the way I mentioned. There is no way to act as a full changeset tool
without either a repository redesign, or a stupid slow layer on top of
the repository which amounts to a repository redesign.
Tom said somewhere that "You shouldn't solve just one case of merging
and claim that you've solved them all." What I'm saying is, solve the
single most common cases of merging, and *don't* claim that you've
solved the others.
For the work I've done with CVS, solving the one case I mentioned
-- in the way I mentioned! -- would be sufficient to remove about
80% of the pain. I think it's worth just doing that ASAP, rather than
waiting for the ultimate tool which eliminates 95% of the pain to become
production ready. And I think that's the niche Subversion should try to
fill.
OK, this was a very long message to say a very short thing. I hope I
said it enough times to get the point across.
--Nathanael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 20 05:27:43 2002