Quoting Kylo Ginsberg <kylo.ginsberg@gmail.com>:
>> So, what would help: a log-call where only log entries belonging to an item
>> existing at a specific revision would send.
>
> Can you elaborate? Do you mean an svn log command which would show
> not just ancestry, but descent and "cousins" for a given file? That
> is quite literally what one wants, but I'm not sure if that's what you
> mean or something else?
I want: svn history -p <rev> <item>
and I get log where <item> and revision <rev> belongs to. eg. copies,
moving, modifications, deletions. Nothing else. Eg., not a range of
revision like in "svn log" now but a range of associated items.
>> TortoiseSvn and kdesvn must get
>> the whole log, parsing it twice (from newest to oldest and back) to detect
>> copies/moves and so on.
>
> Why parsing it twice? Once, newest to oldest to find the root parent,
> then back from the root to find all descendents?
Yes.
Newest to oldest for find the root (at this stage kdesvn modifies the
origin log-entries that way, that in a specific entry is set where the
item in next revision is copied to. how tortoise does it i don't know
exactly but should be same), assigning the copies to the logentries of
the copy-from-revision is necessary 'cause otherwise it isn't able to
detect the branches.
example: /trunk/a at rev 1 is copied to /branches/dev/a on rev 20
so log for rev 20 has copied from "/trunk/a" at rev 1.
Now both clients enhance the logentry for rev 1 internal so: "copy-to
/branches/dev/a in rev 20". you'll understand that this is only
possible when going from newest to oldest log, eg, to addition of
item. eg, newest to oldest must first stage.
oldest to newest is the converting/painting stuff itself (kdesvn
produces a dot-file, tortoise paints direct)
A lot details more but them are real offtopic here I think. but the
cost for such revision tree isn't the smalles one.
>
>> When only getting a specific subset of log....
>
> Does this sentence end: "it would be much faster"? Of have I missed
> your point?
Yes... much faster, less memory usage, less cpu glowing. Sorry.
I'm not sure if this is possible, if this makes sense for subversion
itself or ever should be a client side problem nor if this makes
sense. 'Cause - traffic is the one, the server load the other side.
And I think on a public repository like kde such a feature will kill
the server if a lot clients tries to fetch such a history. Or
subversion tracks this copy-to in a second database on serverside so
the history must not parsed.
so. just my long thougts. hope, i could make a bit clear whats the
problem behind such history feature.
but of course, if I think complete wrong, tell me ;)
Rajko
Received on Fri Mar 23 17:58:23 2007