Re: [Issue 1152] - Client side scripts would allow many requested features

[William Uther <wi...@cse.unsw.edu.au>]

Hi,
   I'm moving this discussion to the dev list.  If I'd thought this was  
controversial I wouldn't have entered it straight into the issue  
tracker.  It has been discussed on the list before without protest  
(which is not to try and dismiss the protest... merely to justify my  
direct entry of it into the issue tracker).

On Tuesday, February 25, 2003, at 02:18  PM,  
issues@subversion.tigris.org wrote:

> http://subversion.tigris.org/issues/show_bug.cgi?id=1152

> ------- Additional Comments From fitz@tigris.org  2003-02-24 19:18 PST  
> -------
> A HUGE -1 on this. I've spent the last 3 years trying to explain to
> people why tar wrappers are evil.  What you are proposing is going to
> break every client that does not have the *exact* same prefs setup
> that you have.

That is not entirely correct.  You need prefs set up to handle the  
scripts used in the working copy - this does not need to be identical  
to someone else's set.  The other options are i) built in  
functionality, or ii) server controlled client side scripts.  Server  
controlled, client side scripts are a HUGE security hole.  Built in  
functionality is nice, but the ability to script something that you  
want that no one else does is also nice.

> We have  3 separate possibilities here:
>
> 1. Tar wrappers.  -1  Please please please don't make me go into why
> this sucks so bad.

If all you are trying to solve is the opaque collection issue, then  
this might not be the best way to do it.  Howver, for interests sake,  
do you have a pointer to why tar is so evil?  I think it would be a  
reasonable, 70% solution.  I'd prefer tar wrappers to nothing.

(The problem with tar that immediately springs to mind is the inability  
to handle resource forks and other Mac meta-data.  Of course,  
subversion already has this problem.  If the collection format is your  
only problem, then the client side scripting solution gives you the  
ability to change that format as you please.)

> 2. File transformations before committing, updating, checking out,
> etc. -1 unless someone comes up with a stunningly elegant solution for
> how to do it, in which case, I'm -0

why?

> 3. Opaque collections (see issue 707).  This is the right way to deal
> with the problem you're trying to hack around with the tar wrappers
> thing. I'm +1 on this, and still trying to come up with the time for
> it. :-)

Great.  Opaque collections are a wonderful idea.  They only give you  
opaque collections though.  They don't give you symlinks, or small  
diffs in compressed xml files (See Alessandro Polverini's recent mail  
"A simple (?) suggestion from a svn fan :)"), or any of the other  
things my proposal can.  Heck, Nutti even mentions checking in /dev  
with his (similar) proposal:

http://subversion.tigris.org/servlets/ 
ReadMsg?list=dev&msgNo=23004&list=dev

This issue is not a specific 'opaque collection' solution.  It is a  
general 'client side scripting' idea, which could be used to work up a  
limited opaque collection solution, if someone chooses to do so.

Be well,

Will       :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and  
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia


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