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

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

From: William Uther <willu_at_cse.unsw.edu.au>
Date: 2003-02-25 07:28:03 CET

   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


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


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  
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
Received on Tue Feb 25 07:29:05 2003

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.