[arch-projects] [PATCH] archrelease: call 'svn copy' once for all files
We don't need to invoke svn copy on each file; it accepts multiple arguments. This cut Allan's time releasing one patch-friendly package from 5 minutes to 2 minutes. Signed-off-by: Dan McGee <dan@archlinux.org> --- archrelease | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/archrelease b/archrelease index 2f6a563..7bb4c8a 100755 --- a/archrelease +++ b/archrelease @@ -52,9 +52,8 @@ for tag in "$@"; do svn add --parents -q "repos/$tag" fi - for file in "${known_files[@]}"; do - svn copy -q -r HEAD "$trunk/$file" "repos/$tag/" - done + # copy all files at once from trunk to the subdirectory in repos/ + svn copy -q -r HEAD ${known_files[@]/#/$trunk/} "repos/$tag/" echo 'done' done -- 1.7.6.1
On Thu, Sep 08, 2011 at 04:38:28PM -0500, Dan McGee wrote:
+1 from me. I wondered why we were looping over the single files in the first place. However, if we copy from current HEAD anyway, I don't see any reason to not just use `svn copy -q -r HEAD "$trunk/" "repos/$tag/"` here.
On Fri, Sep 09, 2011 at 08:44:12PM +0200, Lukas Fleischer wrote:
+1 from me provided we quote the array expansion. $ known_files=(foo "bar baz") trunk=/some/path $ printf '%s\n' ${known_files[@]/#/$trunk/} /some/path/foo /some/path/bar baz $ printf '%s\n' "${known_files[@]/#/$trunk/}" /some/path/foo /some/path/bar baz d
On Fri, Sep 09, 2011 at 02:58:03PM -0400, Dave Reisner wrote:
Well, how is this superior to just copying the whole trunk directory?
On Fri, Sep 09, 2011 at 09:15:03PM +0200, Lukas Fleischer wrote:
No idea. Will svn copy pick up files that aren't tracked? (packages, src/, pkg/, signatures...) d
On Fri, Sep 09, 2011 at 03:24:31PM -0400, Dave Reisner wrote:
Nope, shouldn't. Unless I missed something. We copy from current HEAD and already committed to trunk before, so we shouldn't miss any files when using plain "copy" here.
On Fri, Sep 9, 2011 at 2:29 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Because you'd be reverting the whole damn reason I made these changes in the first place- to prevent the silly extra commit. SVN will *not* let you svn rm a directory and then copy a new one in its place in the same commit. What you suggest is exactly what we used to do: http://projects.archlinux.org/devtools.git/commit/?id=8384ad849dfe308ed3e63e... -Dan
On Fri, Sep 09, 2011 at 02:35:25PM -0500, Dan McGee wrote:
Nope, what I wanted to suggest is `svn rm` the files and `svn copy` the directory thereafter. Obviously, SVN doesn't have any option to copy the content of a directory only, though... :/ So, +1 to your patch with Dave's quoting fix applied :)
participants (4)
-
Dan McGee
-
Dan McGee
-
Dave Reisner
-
Lukas Fleischer