[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Need help/thoughts on tagging scheme

From: Crucius, Wesley <WCrucius_at_sandc.com>
Date: 2004-03-25 15:09:40 CET

Sorry if you're seeing this twice, but my mail server says it wasn't
delivered...

Ok, I'm seriously re-thinking my idea of "tagging" everything. Subversion
is fine with this approach from a performance perspective, but it REALLY
slows down explorer with TortoiseSVN installed (on a 2.4GHz Mobile P4
w/768Meg of RAM). My test case consists of six independant projects with
152 "tagged" revisions in one project, 45 "tagged" revisions in another
project, and 2-10 "tagged" revisions in the other projects. If I have a
Working directory that contains the entire repository "checked-out", then
expanding the root of that tree takes several minutes in explorer,
presumably because Tortoise has to recurse all of the xml files for each
tagged revision to correctly draw the overlay icons.

So, long story short, I'm wondering if it makes more sense to create a label
property on the project folder to track the release-version-string of
"released" revisions? It appears that there is no way to, for example,
checkout the revision who's label property is "pq001v00035r0023"... But can
I can do a "svn proplist --verbose <projectdir>" to generate a
cross-reference list between the value of the(my) "label" property for a
committed revision and the svn revision number of each committed revision
and then checkout the desired revison number accordingly?

Does this make sense? Can somebody give me some advice before my bad
implementation of Subversion and Tortoise ends up giving Subversion a
completely undeserved bad name with my company's "developer community"...

I suppose the most popular recommendation is going to be to simply use tags
more judiciously, but I really do have, as an example, 152 released versions
for one specific project, and that is not all that unusual for the way we
work. Everything is essentially custom, built to order code, based on a
mainline version.

Thanks,
Wes

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 25 15:16:27 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.