On Fri, Jul 18, 2008 at 9:27 AM, Quinn Taylor <quinntaylor_at_mac.com> wrote:
> 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
Point taken - I thought it was more a question of how to
script/customize svn behavior for personal use. I'm not in a position
to opine on the feasibility/desirability of making those changes to
svn itself, but perhaps someone else here can.
>
> Hope this helps,
> Jeremy
>
> Definitely. Accordingly, I hope this clarifies my point.
> - Quinn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-18 20:59:31 CEST