Recursive propedit? No propedit? [was: Re: ignore not recursive to subdirectories]

[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":
>
> Actually, svn:ignore on files is kinda useless. You're really looking
> more for something like:
>
> find . -type d | grep -v '.svn/' | xargs svn propset svn:ignore -F mysvn-ignore

So most of the discussion below is not particularly relevant to svn:ignore, but still relevant to other properties.

cmpilato@collab.net wrote:
> Paul L Lussier <pll@lanminds.com> writes:
>
>>In a message dated: 02 May 2003 08:38:44 CDT
>>cmpilato@collab.net said:
>>
>>>The former. The addition of the -R would cause only two changes to
>>>the way that propedit works today:
>>>
>>> 1) the editor would always be loaded with an empty file (instead of
>>> any current property value(s), if such exist).
>>
>>Why not load with any existing values? If the person invokes
>>propedit, and wants to apply it recursively, they probably want the
>>existing ones. And if they don't, they're in an editor, they can
>>easily delete them.
>
> You have two choices of interface here, then:
>
> - Load *all* the collective values of that property in all the
> recursive targets into the one editor buffer. Well, this is
> silly (I trust you agree).
>
> - Open and close the editor for each and every recursive target.
> Hey, that's fine with me if you want to deal with that sucker
> popping up in your face a hundred times.

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.

cmpilato@collab.net wrote:
> Paul L Lussier <pll@lanminds.com> writes:
>
>>So, if you load the editor with an empty file, would the new props
>>clobber the old, or be added to them?
>
> Clobber, were it my call to make.

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
   targets, and check whether they are all the same as each other.
   If not, give an error. If so, load (one copy of) the value
   into the editor, and afterwards recursively set the edited value.

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.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 3 03:19:40 2003