Re: Newlines when setting svn:ignore from cmdline

Jeremy -

Thanks for the quick turnaround. Judging by your response, I realized
I should clarify...

>> <no effective way to script or automate setting multiple items for
>> a property>
>
> This borders upon shifting the topic from Subversion to shell
> scripting, but how about something like this Bash function
>
> function svn_ignore {
> local target="$1"; shift
> svn ps svn:ignore "`echo $* | tr ' ' '\n'`" "$target"
> }
>
> which would let you do
>
> $ svn_ignore . \*.o \*.exe \*.tmp
>
> It breaks if your ignore patterns have spaces in them, and it only
> works against a single target at a time, but it might work for the
> common case.

I admire your bash scripting kung-fu, and this is a workable solution.
My point is that the way SVN currently handles the situation, everyone
has to write some code like this and use a separate function just to
accomplish the task. I would find it easier if I could do something
like:

        svn propset svn:ignore "*.o *.exe *.tmp" target_dir

or even:

        svn propset svn:ignore "*.o\n*.exe\n*.tmp" target_dir

Currently, the svn command requires an actual newline in between each
item. When I use the second form, the property is actually set with
the \n characters intact.

Since the svn:ignore property requires one item per line, it makes
sense to me that it should be able to intelligently process such a
string without requiring scripting wizardry. I'm a software engineer
and not averse to code solutions, but let's just say that bash is not
mu language of choice. Also, introducing an svn_ignore function is one
more thing for me (or anyone else) to remember, and breaks when I move
to a machine that doesn't have it set up.

>> <can't create a simple alias to set multi-line svn:ignore
>> properties on multiple directories>

> Again, you probably want a function instead of an alias. You could
> supplement the previous function with something like:
>
> function svn_ignore_multidir {
> local dir_pattern="$1"; shift
> # find(1) can't do -exec with a shell function, so loop manually
> for dir in `find . -name "$dir_pattern"`; do
> svn_ignore "$dir" $*
> done
> }
>
> In this case, it breaks if the subdirectories have spaces in the path,
> but since you're using Bash, I assume that isn't a big limitation. To
> reproduce the example in the blog you mentioned, you'd do
>
> $ svn_ignore_multidir \*.xcodeproj \*.pbxuser \*.mode1 \*.mode1v3

Again, I don't really *want* a function, but you're right that this is
what's required currently. And actually, I'm using Bash on OS X, and I
often put spaces in directory names. (Even if I didn't, many Mac users
do.) However, we who use Bash already know how to escape spaces. :-)
If svn were to intelligently handle insertion/translation of newlines,
I could use a simpler alias for something specific like this:

        alias xcode_ignore ="find . -type d -name '*.xcodeproj' | svn propset
svn:ignore '*.pbxuser\n*.mode1\n*.mode1v3'"

and only call

        xcode_ignore

I realize in the end I could define xcode_ignore to call
svn_ignore_multidir with the same pattern, so please don't think I'm
ignorant. :-) I just think that the functionality for translating
newlines is something that, if built into svn itself, could make it
more usable by more people without resorting to nearly indecipherable
(although extremely clever) shell scripting.

Further, proposed solutions such as these tend to scare away the non-
technical crowd. Subversion may not be actively campaigning to people
unfamiliar with version control, but like it or not, it is starting to
attract that demographic to some degree. Expecting them to write such
scripts themselves will be an exercise in futility. Even setting multi-
line properties right now gets people confused.

Adding \n escaping would make a lot of sense to programmer types like
myself, and make Subversion easier to work with in general, which I
sense is the goal. As it is, the current approach feels more like the
ugly syntax I'm used to seeing in my less-than-pleasant interactions
with CVS. :-P

> Hope this helps,
> Jeremy

Definitely. Accordingly, I hope this clarifies my point.
  - Quinn