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

Re: peg-rev and checkout

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2006-05-06 16:23:58 CEST

Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:

> I'm not sure that we _can_ trace forward in time at the moment.
> Without 'proper' rename support, we could potentially encounter any
> number of 'copied-to' nodes along the path from the earlier to the
> later revision.
> For example, in your example, r2 is:
> - delete dir1
> - create dir2 as a copy of dir1 at r1.
> But you could also have had:
> - delete dir1
> - create dir2 as a copy of dir1 at r1.
> - create dir3 as a copy of dir1 at r1.

Ah right! Now I see, thanks!

> Which node should be returned? While we could probably 'guess' the
> correct node in many cases, I think a better solution is to wait until
> we stop representing renames as copy+delete, because we can trace
> through renames with ease.

Will there be a tool to convert an old repository with "fake renames" into
"real renames" (possibly - but not necessarily - withouth having to go through
a full dump/load cycle)? If this tool is not planned / will not exist, the
forward-trace heuristic you speak of (guessing fake renames as real renames)
might be worth it.

> (Tangentially related: issue 2496, which is about tracing forwards
> into 'no-change' revisions).

Yes. As I already heard complaints about this kind of issues, I can assure they
are really annoying for users :)

Giovanni Bajo

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 6 16:25:24 2006

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