Greetings,
I'm new to Subversion and this list, so forgive me if I'm being naive, but
it seems to me the ideal solution to this problem would be some form of
server-side pluggable content handlers. If the checkin/checkout/search/etc
interfaces are abstracted, then we can create modules to handle the details
of these operations for different file types, based on MIME type for
example. The file type could be specified during initial checkin (if it's
not obvious from the extension) and kept in the property list. Thus
operations could be optimized for different file types, and new modules
could be built and added dynamically to support new file types.
This addresses fitz's concerns regarding tar wrappers and prefs setup, and
eliminates William's security concerns of server-controlled client-side
scripts. It would work well with the idea of opaque collections. I don't
know if it qualifies as a "stunningly elegant solution"... but it seems like
a decent idea to me...
Or am I talking out of my rear-end??
James
> -----Original Message-----
> From: William Uther [mailto:willu@cse.unsw.edu.au]
> Sent: Tuesday, February 25, 2003 1:28 AM
> To: fitz@tigris.org
> Cc: dev@subversion.tigris.org
> Subject: Re: [Issue 1152] - Client side scripts would allow many
> requested features
>
> > ------- 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 25 15:50:23 2003