On Fri, Jul 24, 2009 at 3:54 AM, Erik Huelsmann<ehuels_at_gmail.com> wrote:
> On Thu, Jul 23, 2009 at 5:37 PM, Seak, T. F.<lapsap7+svn_at_gmail.com> wrote:
>> On Wed, Jul 22, 2009 at 20:50, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>>>
>>> In Tortoise open your repo browser. Find the tag in question. Right click
>>> on the tag folder and select "Show Log". At the bottom of the log dialog
>>> click the "Stop on Copy" check box. Look in the Action list. If you see one
>>> log item and action there "Added" with a single Path/Copy From Path then
>>> this was an svn copy.
>>>
>>> If you see many log items there with tons of files added then it probably
>>> imported each file into the tag separately.
>>
>>
>> Please take a look at the attached image (if this mailing-list doesn't
>> filter it). Indeed, for a certain revision (85361) whose date corresponds
>> to PVCS days, there are a lot of "added". I suppose this is what you meant
>> by "imported each file into the tag separately".
>
> Actually, that's not true: the revision you're showing contains
> "Added" actions, but the column "Copy from" is also filled, that tells
> me this revision was created efficiently. It would be interesting to
There's something mental about that 'tag'. It's the same file at the
same revision copied many many times, each time to a different tag.
This looks like it builds a tag from copies for each member of the
tag.
Those copies are 'cheap' but enough of them adds up. For tagging to
really be cheap you would need to see something like "cp .../foo/trunk
.../foo/tags/X" - tagging the entire trunk at a time, not a tag per
file.
This has issues, for one it's hard to track that tag back through
history to its source as the log of tag root won't be helpful.
It might be worth looking on disk at the size of that revision
(assuming it's not a packed svn 1.6 repo) just to verify that it is
this tag strategy that's contributing so much to repo size. If it is
this tagging strategy at fault then you're stuck with the cost unless
a new import can better organise the history into tagged slices of
time rather than each tree element at time.
--
Talden
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374994
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-23 23:29:49 CEST