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

Re: svn commit: rev 1957 - trunk/subversion/include trunk/subversion/libsvn_wc

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-05-15 00:56:08 CEST

Greg Stein wrote:

>On Wed, May 15, 2002 at 12:23:35AM +0200, Branko Äibej wrote:
>>Just a minute. Are you doing all this work /instead/ of adding reference
>>nodes to the filesystem? And this will all get ripped out once we have
>>reference nodes? Sorry, but I don't like that at all.
>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?)

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.

>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. Observe that you're
already disagreeing on the semantics of the "svn:module" prop.

>>I also didn't find any design doc for this feature, discussing pros and
>>cons and tradeoffs vs. reference nodes. I only remember one or two posts
>>to the dev list, without any real conclusions.
>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.

>>(Can you point me to the relevant messages if I missed them? Thanks.)
>Vetoes require a specific technical problem; preferably with solutions for
>rectifying that problem. Is there something technically wrong with this
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.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 15 00:57:07 2002

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.