Re: Complex tag creation performance

On Tue, Jun 27, 2006 at 12:29:17PM +0200, Robbie Gibson wrote:
> We have a simple SVN setup where everybody works in the trunk. When we want
> to put our work into the production system we do a selective update of the
> files concerned - that is, we work on a file-by-file basis and hardly ever
> do a global "svn up" on the production systems. To keep track of production
> versions we create a complex tag with svn cp WC URL.

I do something similar. I am using svn for tracking system
configuration files. Since there are multiple independent subsystems in
the tree, and multiple people working in the tree, the production tree
is almost never the head revision of the working tree. This leaves
each file in the production tree at a different merge revision making
merge tracking difficult at best.

I would be interested in your mechanisms for tracking this sort of
thing. I have used properties to track the merge revisions for each
file, but it's far from automated. Also the lack of a single command
to search all revisions of a file/files for a property leads to a lot
of:

  for i in `svn log -q $1 | sed -ne 's/^r\([0-9]*\).*/\1/p'`
  do
   property=`svn propget --revprop -r $i mergepoint $1`
   [ -n "$property" ] && echo "$i $property"
  done

which puts out lines like:

  571 work/Config/bin/Rdist:490

which means that revision 571 of Rdist was the result of the merge
from revision 490 of work/Config/bin/Rdist.

> This works fine, except that after a few months we started noticing
> a slowdown in the tag creation.
>
> Investigations showed that the "svn cp" was checking the version of every
> file to find the oldest revision and then using that as the basis for the
> tag, plus changes since. As we never do a global update and some files
> seldom change, the oldest revision could be 6 months ago - even if every
> file is completely up to date!
>
> To get over the problem I have written a small script which "updates" files
> with no pending changes to the latest version (i.e. my script updates the
> metadata for up-to-date files and directories). It's a bit slow but it
> seems to help. I have three questions:
> 1) Is this behaviour described by design, or is it a bug?
> 2) Does anybody have a better suggestion for how to resolve my problem?

Would merging into and committing a separate production branch and then
tagging that branch speed things up? (At the cost of having to do the
merge). At the very least it should have fewer revisions in it than
your trunk tree. With a production branch you aren't building a tag
tree from scratch each time. Instead you are building it from only
released copies of your files.

Also some form of delete updated files from the production branch,
copy the files for the release into the production branch, tag may
work as well. I submitted a question on that a bit ago. The list
archives should have the thread.

-- 
				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org