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

Re: Suggestion for special file storage in 1.0

From: Colin Watson <cjwatson_at_flatline.org.uk>
Date: 2002-10-11 23:18:55 CEST

On Sat, Oct 12, 2002 at 12:06:51AM +0300, Nuutti Kotivuori wrote:
> Barry Scott wrote:
> > Why don't you place these steps into a makefile?
> >
> > WHy not add user defined attributes and use external
> > tools to do the special handling?
>
> I talked about this in my message. I'd hate to repeat the same thing
> again. You could atleast consider telling why the cases I presented
> there are not valid and should be handled otherwise? Here is a small
> excerpt.
>
> ,----
> | For normal source code storage in a repository, special files are
> | almost never needed. But source code is not the only thing people
> | want to store in a repository. Some people want to have their whole
> | home-directory as a working copy.

Ack. That's exactly what I'm trying to do. A Makefile would be an ugly
wart on my home directory, and, while I'm in the process of developing a
system for using user-defined properties and an 'svnfix' script to deal
with symlinks and other things for me, it seems like using a rather
large sledgehammer that each user must reinvent to crack a rather small
and standardizable nut.

(Not to mention that properties, especially the multi-line kind, are
still rather awkward to reliably parse automatically, although the 'svn
propget -R' patch I posted a day or two ago does help somewhat.)

I'm a mere user and interested observer of Subversion, but it does seem
to me that Subversion is exactly the right place for this functionality.

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 23:19:37 2002

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.