Recursive propedit? No propedit? [was: Re: ignore not recursive to subdirectories]
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-05-03 03:25:20 CEST
[For a quick summary, see the last two paragraphs.]
The original request was for something like "svn:ignore" but that could be set on one directory and would take effect on that directory and recursively on all subdirectories. More than one person has requested that, but it is not available at present and not likely to be implemented soon.
The thread then discussed how "propedit" could be made to operate recursively, analogously to "propset -R".
cmpilato pointed out that "propset -R" is not particularly appropriate for use with "svn:ignore":
So most of the discussion below is not particularly relevant to svn:ignore, but still relevant to other properties.
There are more than two options. But first we should agree what the aim or requirement is. It seems to me that "propedit" has TWO purposes:
(1) Provide an easy way to use a text editor to compose the property value.
(2) Provide an easy way to modify the old value of a property rather than typing it all in again.
Note that purpose (1) without (2) could reasonably be served by something like "propSET --editor[=EDITOR]" (although that is not available at present). Therefore I see purposes (1) and (2) together as being the important goal.
With "propSET --editor", fine. With "propEDIT", I hope not. But it depends on one's view of exactly what "propEDIT" means.
Now, what would a user want from a RECURSIVE "propedit" command? You mention two options above. The second one could be useful in some situations, but not often. Your first suggestion is silly as you state it, but a useful variation that satisfies (1) and (2) would be:
- Read *all* the values of that property in all the recursive
There are other possibilities too.
All of these goals could be accomplished by external programs or scripts using propget and propset. So could some other useful semantics like adding or removing parts of a property: "propedit -R svn:ignore += '*.o'". The implementation of semantics like "+=" would of course need knowledge of the format of the particular property, so would no longer be a general-purpose property editing command.
My personal feeling is that we should make a clear distinction between the CORE commands - the commands like "propget" and "propset" which are necessary and which could reasonably be used by higher level external programs - and the handy extensions like "propedit" which are just short cuts. I am not saying that "propedit" has to be implemented as an external script, but that it ought at least to be documented as a "secondary" command.
So I can see lots of nice things that "propedit" could do, but because of the endless possibilities for variation and enhancement I don't think it deserves as high a priority as the core commands.
This is an archived mail posted to the Subversion Dev mailing list.