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

Re: [RFC] SVN 1.1.x: Shared Files

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-23 02:44:03 CEST

David Balch wrote:

> Hi,
> Sir Woody Hackswell wrote:
>> Here is a tiny little proposal for the basis of shared file
>> (repository-side linking) in Subversion. Constructive input or
>> output would be welcome.
> This sounds good, and is a feature that I would appreiciate. I have an
> observation on the implementation suggested...
> <snip>
>> ---------------
>> 3) Each share in a group of shared files shall have a list of all
>> other related
>> shared nodes, so that upon update, all other shared nodes may be
>> updated to the
>> new root node.
> I'm no expert programmer, but that sounds like an inneficient way to
> do it [O(n) perhaps?], which could cost if numerous files are shared.

At least. It's also far too complicated.

> Might it be better for only the root share to have the list of shared
> nodes, and any share update goes to the root share, and is then
> propgated to other secondary shares if relevant. This would avoid
> having to update n secondary shares when simply adding 1 new secondary
> share.

No, actually it would be best if, instead of trying to simulate VSS's
broken idea of shared files, we implement something that behaves like a
symbolic link. That is, there's no backpointer from the linked-to file
to the links. Remember that VSS uses shares as the basis of its branch
implementation, that's why it needs the two-way cross reference.
Subversion definitely doesn't need another branching scheme. :-)

(The WC layer could maintain such backpointers if both the link and the
original are part of the same WC tree, in order to propagate changes
correctly. But it's not necessary.)

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 23 08:19:45 2004

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.