On Jul 23, 2009, at 2:28 PM, Talden wrote:
> 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
If it is a packed version of a 1.6 repos, just look at the appropriate
lines in the manifest file.
> 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
> ].
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2374998
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-23 23:37:28 CEST