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

[David Balch <da...@conted.ox.ac.uk>]

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>

> IMPLEMENTATION:
> ---------------
> 
> 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.

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.

My 2p worth :-)

Cheers,
Dave.

-- 
David Balch.          | Web developer.
T: +44 (0)1865 286932 | Technology-Assisted Lifelong Learning.
F: +44 (0)1865 286922 | University of Oxford.
E: david.balch<at>conted.ox.ac.uk

TALL, OUDCE and the University of Oxford accept no legal responsibility 
for the contents of this message. Any views or opinions presented are 
only those of the author and not those of TALL, or OUDCE, or the 
University of Oxford. If this email has come to you in error please 
delete it and any attachments


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Branko Čibej <br...@xbc.nu>]

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>
>
>> IMPLEMENTATION:
>> ---------------
>>
>> 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