You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/11/18 18:46:17 UTC
Re: "textual binary" MIME types (was Re: file locking and binary
files)
On Mon, 2002-11-18 at 12:59, Eric Gillespie wrote:
> Hard-coding configuration data (yes, that's what it is) in your
> code is generally considered a bad idea.
I disagree with both of you. This isn't configuration data, this is
information. No one has an interest in configuring whether
image/x-xbitmap is composed of text or not. They may have an interest
in adding application/x-localtype, but that doesn't turn the contents of
the default list into configuration data.
The "magic" file used by the Unix file command is a good analog. It can
never be complete because people create new file formats, so you want it
to be easily updated, but it's not configuration. It generally lives in
/usr/share/magic on modern systems. You could imagine allowing an
/etc/localmagic where people could add magic for local file formats, but
it doesn't look like file supports that (and I don't think anyone really
cares).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 18 November 2002 21:07, Benjamin Pflugmann wrote:
> > I *do* have a problem with the natural consequence of your and
> > Greg's point of view: not being able to remove the default items
> > from the list.
>
> That is not a consequence, but a pre-condition. At least for me - I
> cannot talk for Greg here, but it was how I understood Greg. And I
> thought I made clear that I consider it a pre-condition ("there should
> be no reason to ever change any existing item").
One thing to consider is that in the future, there might be a need for such a
thing as configurable diff/merge programs. For example, for
"{text,application}/xml" or "*/*+xml", use some XML-specific merge program,
for "text/*" use the default built-in merge, and for other types do no merge.
The logical place to configure these associations would be in the same config
file as the text/not-text lists that we are discussing today. If the default
list is hardcoded in the svn binary, then that would have to change in the
future anyway in order to allow respecification of the default diff/merge
programs for those mime-types.
Are you still following me? :-) My point is that although it does seem like
there is not a reason today, there could be a reason to change a default
item in the future.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE92c7EhDAgUT1yirARAqXtAJ0dp+J5FDPYd3n4dSwLheQgINLzdQCfUaHB
CVr0N+egZNyQ9aWjkpau4Fo=
=kEeK
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Mon 2002-11-18 at 19:08:22 -0500, Eric Gillespie wrote:
> Benjamin Pflugmann <be...@pflugmann.de> writes:
[...]
> > There is a difference: As Greg pointed out, one never wants to
> > change the default. More precisely: one might want to append to
> > the list, but there should be no reason to ever change any
> > existing item. As a whole list, it is configuration data, the
> > default items are not.
>
> What a strange way to conceive of it.
No. Just an extreme way to express it to pin down a difference.
> The configuration data in discussion is a list. This list has a
> default value, (1 2 3 4). Changing the list to (1 2 3 4 a b c) is
> changing the list; that all the default elements are present does
> not mean the list has not been configured.
Agreed.
> To say that (1 2 3 4) is some default data but the configurable list
> defaults to () but the administrator may change it is true from a
> certain point of view, but it seems a very contorted way to view
> things.
You lost me here. Either I am simply not able to follow or you
misunderstood what I was saying.
[...]
> I *do* have a problem with the natural consequence of your and
> Greg's point of view: not being able to remove the default items
> from the list.
That is not a consequence, but a pre-condition. At least for me - I
cannot talk for Greg here, but it was how I understood Greg. And I
thought I made clear that I consider it a pre-condition ("there should
be no reason to ever change any existing item").
> The list needs to be configurable, not described in some contorted
> way such that the user is allowed only to add to the list, never
> subtract from it.
Why? Why does one need to be able to set that image/x-xbitmap is
binary?
I thought the whole point was that being some text form is a fixed
property of mime types, not something that would change.
"No one has an interest in configuring whether image/x-xbitmap is
composed of text or not"
Do you agree or not? If not, we can stop right here, because we are
talking at cross-purposes. Greg made that claim, I did not see you
deny it (or misunderstood you) and therefore assumed that this is a
common basis. All I said implied that claim. So if you do not agree,
we were talking about different things.
Bye,
Benjamin.
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Benjamin Pflugmann <be...@pflugmann.de> writes:
> I think you missed Greg's point.
No, i see his point, i just disagree with it. I thought that
highlighting the contradiction i see in what he said might
provide some enlightenment as to why we disagree.
> There is a difference: As Greg pointed out, one never wants to
> change the default. More precisely: one might want to append to
> the list, but there should be no reason to ever change any
> existing item. As a whole list, it is configuration data, the
> default items are not.
What a strange way to conceive of it. The configuration data in
discussion is a list. This list has a default value, (1 2 3 4).
Changing the list to (1 2 3 4 a b c) is changing the list; that
all the default elements are present does not mean the list has
not been configured. To say that (1 2 3 4) is some default data
but the configurable list defaults to () but the administrator
may change it is true from a certain point of view, but it seems
a very contorted way to view things. Certainly it isn't the way
any application i've ever seen presents things.
> > If you want to have the defaults in
> > the code, that is fine, i will not argue against that.
> [...]
>
> That is exactly what he says: The default list is not configuration
> data, therefore it is not automatically bad style to put the default
> list into the code (this is what it was all about, before).
You quoted me out of context. It is true that i have no problem
with the default list being in the code. I *do* have a problem
with the natural consequence of your and Greg's point of view:
not being able to remove the default items from the list. The
list needs to be configurable, not described in some contorted
way such that the user is allowed only to add to the list, never
subtract from it.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Mon 2002-11-18 at 14:09:17 -0500, Eric Gillespie wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> > I disagree with both of you. This isn't configuration data,
> > this is information. No one has an interest in configuring
> > whether image/x-xbitmap is composed of text or not. They may
> > have an interest in adding application/x-localtype, but that
> > doesn't turn the contents of the default list into
> > configuration data.
>
> You contradict yourself. First you say the list is not
> configuration data, then you say the list should be configurable.
I think you missed Greg's point.
> The list *is* configuration data; like most configuration data,
> it has a set of defaults.
There is a difference: As Greg pointed out, one never wants to change
the default. More precisely: one might want to append to the list, but
there should be no reason to ever change any existing item. As a whole
list, it is configuration data, the default items are not.
> If you want to have the defaults in
> the code, that is fine, i will not argue against that.
[...]
That is exactly what he says: The default list is not configuration
data, therefore it is not automatically bad style to put the default
list into the code (this is what it was all about, before).
Bye,
Benjamin.
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> If you get a chance, file a Post-1.0 issue for the extensible
> mime-type thing.
http://subversion.tigris.org/issues/show_bug.cgi?id=1002
One complaint about Issuezilla. I thought the Post-1.0 Milestone
had been deprecated in favor of a post-1.0 keyword (i see i was
confusing it with bite-sized). When i tried to submit the
post-1.0 keyword change, Issuezilla responded with a blank page
(it still had the Tigris.org bandwidth waste, but the content
area was empty). No error message or anything. I searched
through my svn issues folder and found it was bite-sized i was
thinking of and then understood. Note that Bugzilla does not
have this particular defect (though i imagine whatever ancient
version was transformed into Issuezilla did have the bug, along
wiith who knows how many others; don't you just love effort
duplication?).
> (There appears to be no significant disagreement over what the
> functionality should be, only over the definition of the word
> "configuration", a debate I'm happy to stay as far away from as
> possible, ahem).
Don't take this as my trying to draw you into this argument, but
upon reading your comment it occurs to me some people might have
the idea i'm a raving lunatic obsessing over semantics. At least
in this particular case, that isn't what's going on. The natural
conclusion of the position i see Greg Hudson taking (that we have
a hard-coded "default" which is not itself configurable) leads to
the natural conclusion that the separate, configurable list can
only add to, not subtract from, the default. That points at the
fundamental mistake: there is one configuration item in question,
the list of types. It has a default, hard-coded or not. And
once you go there, the question is why have it in the code at
all? Just let the automatically installed configuration file
hold the defaults.
IMHBCO anyway ;->.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> > Thanks for saying it, Eric, appreciated.
>
> >blush<
>
> I may be a pain in the ass, but i like to think i'm one of the
> good guys :).
And where would the free software world be without pains in the ass,
anyway? :-)
If you get a chance, file a Post-1.0 issue for the extensible
mime-type thing. (There appears to be no significant disagreement
over what the functionality should be, only over the definition of the
word "configuration", a debate I'm happy to stay as far away from as
possible, ahem).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Thanks for saying it, Eric, appreciated.
>blush<
I may be a pain in the ass, but i like to think i'm one of the
good guys :).
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Eric Gillespie <ep...@pretzelnet.org> writes:
> Note that this will *not* be happening for 1.0 unless someone
> outside CollabNet provides the code. The mechanism for
> retrieving configuration data has yet to be decided upon, much
> less implemented, and will not be until later.
Thanks for saying it, Eric, appreciated.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
kbrannen@gte.net writes:
> come out and say it. Anyway, the bottom-line to me is that
> this list should *not* be in code. Therefore, a "config" file
> sort of thing seems to be the obvious thing to do. And yes,
> locally modifiable is something to keep in mind.
Note that this will *not* be happening for 1.0 unless someone
outside CollabNet provides the code. The mechanism for
retrieving configuration data has yet to be decided upon, much
less implemented, and will not be until later.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary
files)
Posted by kb...@gte.net.
Sebastien Cevey wrote:
> On Mon, Nov 18, 2002 at 03:46:50PM -0600, kbrannen@gte.net wrote:
>
>
>>Not that we have to do it the CVS way, but I recall a file in
>>/<cvsroot>/CVSROOT that held patterns for binary file names (I'd go
>>look it up but I've already deleted my last CVS install. :-)
>
>
> Are you talking about this file :
>
> ----------------8<------------------
> [seb@sirius CVSROOT]$ cat cvswrappers
> # This file affects handling of files based on their names.
...
> #*.gif -k 'b'
> [seb@sirius CVSROOT]$
> --------------8<---------------------
Yes! Thanks for digging that up!
>
> Sounds like it, although it doesn't care for mime-type but file
> pattern of course.
True, as I had pointed out, but it was the concept I was after. :-)
>
> Anyway, I think an external (and possibly modifiable) type list would
> be a lot cleaner than a hard coded list. It would also allow people
> using "custom" (cute name for non-standard) mime-types to specify
> their own file handling.
>
> But the main idea is really nice ! :)
>
The discussion seemed to be trying to go that direction, so I thought I'd just
come out and say it. Anyway, the bottom-line to me is that this list should
*not* be in code. Therefore, a "config" file sort of thing seems to be the
obvious thing to do. And yes, locally modifiable is something to keep in mind.
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Sebastien Cevey <se...@cine7.net>.
On Mon, Nov 18, 2002 at 03:46:50PM -0600, kbrannen@gte.net wrote:
> Not that we have to do it the CVS way, but I recall a file in
> /<cvsroot>/CVSROOT that held patterns for binary file names (I'd go
> look it up but I've already deleted my last CVS install. :-)
Are you talking about this file :
----------------8<------------------
[seb@sirius CVSROOT]$ cat cvswrappers
# This file affects handling of files based on their names.
#
# The -t/-f options allow one to treat directories of files
# as a single file, or to transform a file in other ways on
# its way in and out of CVS.
#
# The -m option specifies whether CVS attempts to merge files.
#
# The -k option specifies keyword expansion (e.j'ai. -kb for binary).
#
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
#
# wildcard [option value][option value]...
#
# where option is one of
# -f from cvs filter value: path to filter
# -t to cvs filter value: path to filter
# -m update methodology value: MERGE or COPY
# -k expansion mode value: b, o, kkv, &c'est
#
# and value is a single-quote delimited value.
# For example:
#*.gif -k 'b'
[seb@sirius CVSROOT]$
--------------8<---------------------
Sounds like it, although it doesn't care for mime-type but file
pattern of course.
Anyway, I think an external (and possibly modifiable) type list would
be a lot cleaner than a hard coded list. It would also allow people
using "custom" (cute name for non-standard) mime-types to specify
their own file handling.
But the main idea is really nice ! :)
--
Sebastien Cevey <se...@cine7.net>
Cine7 - www.cine7.net
Milcis - www.milcis.net
ICQ: 48895760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
May I suggest that we leave this thread until we're implementing it?
(Unless you actually *are* implementing it, in which case it's
important to have the discussion now, I guess).
Being "right" now isn't useful, since we're not writing the code until
Post-1.0.
Thanks,
-K
Eric Gillespie <ep...@pretzelnet.org> writes:
> > * If someone does want to add a local type, it should not be
> > done by editing the default list, because that would get in the
> > way of Subversion upgrades. (Either an upgrade leaves the
> > modified list alone, in which case new types known to
> > Subversion don't show up, or the upgrade stomps on the modified
> > list.)
>
> Subversion upgrades have no business overwriting config files in
> sysconfdir, much less in the repo config dir.
>
> --
> Eric Gillespie <*> epg@pretzelnet.org
>
> Build a fire for a man, and he'll be warm for a day. Set a man on
> fire, and he'll be warm for the rest of his life. -Terry Pratchett
>
> ---------------------------------------------------------------------
> 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
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Hudson <gh...@MIT.EDU> writes:
> I think everyone missed this. I don't think Subversion's list should be
> in the code (though I don't think it's a travesty that it lives there
> for now), and I don't think it should be in a config file. I think it
> should be in a data file under ${datadir} (or the Windows equivalent).
What does having two lists (one global, one per-repository; one
configurable, one not) buy you over a single, per-repository,
customizable list with default contents? Later you even refer
to the multiple-file setup as simpler? I don't see how.
> As a separate matter, it might be valuble to let people add
> local types (application/x-local-text-based-file-type). It
> doesn't really seem worth the complexity, but I wouldn't scream
> and yell about it. However:
It doesn't seem worth the complexity? It's going to be worth the
complexity to the people who *do* have local types. More
importantly, there are hundreds of MIME types today, many used
only for specialized purposes. Do you really think the svn team
will enumerate them all as well as correctly identify their
textual or non-textual status? What about the ones that are
inevitably forgotten? What about the ones that come out between
release (or, more likely, move from being an x-foo type to a foo
type).
> * I don't see any value in letting people remove items from
> the default list. If we added an item by mistake, that's a
> bug, and there's no requirement that users be able to work
> around bugs through configuration.
Like i asked earlier, what does the multiple file scenario buy
you over the single per-repository file? Even Karl agrees we do
want it configurable long-term, so why not just go with that
single file?
> * If someone does want to add a local type, it should not be
> done by editing the default list, because that would get in the
> way of Subversion upgrades. (Either an upgrade leaves the
> modified list alone, in which case new types known to
> Subversion don't show up, or the upgrade stomps on the modified
> list.)
Subversion upgrades have no business overwriting config files in
sysconfdir, much less in the repo config dir.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary
files)
Posted by Greg Hudson <gh...@MIT.EDU>.
I wrote:
> > I disagree with both of you.
I think everyone missed this. I don't think Subversion's list should be
in the code (though I don't think it's a travesty that it lives there
for now), and I don't think it should be in a config file. I think it
should be in a data file under ${datadir} (or the Windows equivalent).
As a separate matter, it might be valuble to let people add local types
(application/x-local-text-based-file-type). It doesn't really seem
worth the complexity, but I wouldn't scream and yell about it. However:
* I don't see any value in letting people remove items from the
default list. If we added an item by mistake, that's a bug, and there's
no requirement that users be able to work around bugs through
configuration.
* If someone does want to add a local type, it should not be done by
editing the default list, because that would get in the way of
Subversion upgrades. (Either an upgrade leaves the modified list alone,
in which case new types known to Subversion don't show up, or the
upgrade stomps on the modified list.)
Your conception of the text-based MIME types as a single configurable
list isn't really workable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Hudson <gh...@MIT.EDU> writes:
> I disagree with both of you. This isn't configuration data,
> this is information. No one has an interest in configuring
> whether image/x-xbitmap is composed of text or not. They may
> have an interest in adding application/x-localtype, but that
> doesn't turn the contents of the default list into
> configuration data.
You contradict yourself. First you say the list is not
configuration data, then you say the list should be configurable.
The list *is* configuration data; like most configuration data,
it has a set of defaults. If you want to have the defaults in
the code, that is fine, i will not argue against that. But, you
can also have the defaults simply be the default state of the
file. Not having the file at all is a problem, but like i said,
a problem people can accept in a 1.0 release.
> The "magic" file used by the Unix file command is a good analog.
Not really. Hard-coding the list into the file bianry would be a
good analog. Is /usr/share the right place for the file?
Possibly. At least the file exists.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary files)
Posted by Eric Gillespie <ep...@pretzelnet.org>.
kbrannen@gte.net writes:
> I'm sure that's what's floating around in the idea above, but I
> thought I'd mention the CVS remedy, so we can steal an idea if
Yes, that's exactly what Karl and i were talking about. A
post-1.0 feature giving the client a way to retrieve
configuration data from the repository is planned.
A magic directory whose commits are automatically populated into
the repository configuration is a completely separate feature
that i believe is required, and i think i convinced Sussman of
this on IRC once, many months ago. In any case, i will wait for
post-1.0, when repository configuration is being planned, to make
the case for this feature here on the list. For now, i'd rather
not get into it.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "textual binary" MIME types (was Re: file locking and binary
files)
Posted by kb...@gte.net.
Greg Hudson wrote:
> On Mon, 2002-11-18 at 12:59, Eric Gillespie wrote:
>
>>Hard-coding configuration data (yes, that's what it is) in your
>>code is generally considered a bad idea.
>
...
> The "magic" file used by the Unix file command is a good analog. It can
> never be complete because people create new file formats, so you want it
> to be easily updated, but it's not configuration. It generally lives in
> /usr/share/magic on modern systems. You could imagine allowing an
> /etc/localmagic where people could add magic for local file formats, but
> it doesn't look like file supports that (and I don't think anyone really
> cares).
Not that we have to do it the CVS way, but I recall a file in
/<cvsroot>/CVSROOT that held patterns for binary file names (I'd go look it up
but I've already deleted my last CVS install. :-) Anyway, why couldn't we do
somthing like that? OK, it'd probably list mime-types instead of file
extensions, but it should work.
I'm sure that's what's floating around in the idea above, but I thought I'd
mention the CVS remedy, so we can steal an idea if need be. (Maybe make the
list a repository property?)
HTH,
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org