On Wed, May 15, 2002 at 12:56:08AM +0200, Branko Äibej wrote:
> Greg Stein wrote:
>...
> >The reference nodes are a different concept. While they might be able to do
> >inter-repository "modules", they won't be able to do intra-repos modules.
> >If/when those nodes arrive, the client-side modules would remain.
>
> (I'm guessing you meant just the opposite: Will be able to simulate
> modules within the same repository, but not from other repos?)
My understanding of any kind of new node in the FS would be that it refers
to internal items, rather than external pointers. So yah.. maybe I got my
"inter" vs "intra" mixed up; basically, I was saying that a ref node design
wouldn't be able to refer to other/arbitrary repositories.
> I don't see this limitation. Since we haven't discussed reference nodes
> much at all, it's not surprising we have different models in mind.
True enough :-)
> >This approach is also a great way to handle modules. It is very user
> >approachable/editable (heck, even under revision control), and can easily be
> >handled entirely on the client side. No funky FS tricks.
> >
> >Low dev bar. High functionality. Parity with CVS (maybe better).
>
> Using a text file to express FS metadata is bad enough, but using the
> client to implement FS functionality is evil.
I don't see modules as being an FS concept at all. That is one of the
reasons why I like this design. "modules" are all about a handy way for the
client to construct a particular working copy. Repeat: working copy.
"grab this from here. that from over there. oh, and this extra bit goes
right there."
It's all about the client and the working copy.
> Observe that you're
> already disagreeing on the semantics of the "svn:module" prop.
No. The property is no big deal. The disagreement is on property
inheritance. I say "no way [for 1.0]".
>...
> >All in the issue.
>
> Yah, saw that now, my mistake for not looking there before. But IMHO
> such discussion should be held on the dev list, and culminate in a
> document. The issue tracker is nice for tracking issues, but not for
> design discussions.
If you want to take the time to write that document, then please feel free.
You know as well as the rest of us, that time is always limited. And, as
Karl pointed out, there *was* some discussion on the list.
>...
> >Vetoes require a specific technical problem; preferably with solutions for
> >rectifying that problem. Is there something technically wrong with this
> >approach?
>
> I should have qualified that with "until this feature has been discussed
> at length". I thought I had made my objections obvious. Right now, I see
> more minuses than pluses in this feature.
I read your position as "this should be handled by reference nodes" but not
much more than that. If you're vetoing simply to stop work until more
discussion has occurred, then I'll have to raise a yellow flag :-)
[ as a general background (read: not necessarily aimed at Branko): it is
incumbent upon the vetoer to apply the necessary time to do their review,
raise technical problems / suggest alternatives, etc; a veto cannot hold
up others' work until the vetoer has more time ]
In any case, Karl has posted a longer note about the modules approach. I'd
suggest that you aim your concerns/issues/review of the (current) approach
at that branch of this thread :-)
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 Wed May 15 02:18:36 2002