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

Finding other descendants - efficiently

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2007-04-03 16:15:40 CEST

The question of finding the copy sources (see "[RFC] Identifying
copy/move sources" email thread) rekindled a "need" to do the inverse
- finding where a file/revision was branched/copied to.

That is, it would be great to find where a specific revision of a file
was copied to such that I could, for example, track down all branches
that may need a specific fix or other "genealogy" type attributes from
the trunk or source file. (One that I was hoping to provide is a way
to find the "branches" that could be merged back to this part of
trunk, but that is being solved in our development process and naming

Right now, this process is hard for a few reasons:

1) Using normal interfaces you can only really find the source of a
copy, not the destination(s).

2) Even if you get the whole repository log (including the path
details which is needed to find the copies) it does not always
indicate the file but just the directory. This complicates things,
especially when the tag/branch came from a mixed revision working

3) Even if we can solve the #2 complexity, there is the fact that
getting the whole log from a large repository with many revisions is
very, very costly.

Now, I understand that this may not be easily done. In fact, given
how the FS works, there is little in the way of any forward linkages
(hey, it is a DAG, so why would there be). Also, the fact that past
revisions do not get modified is a major win for a number of reasons,
so where would such information be stored. (I have thought about
doing this in a post-commit hook and storing some path/revision texts
within a revprop but...)

Does anyone have a better idea of what could be done? Maybe the
performance and size of the log issue will get greatly reduced by the
--only-copies capability. That may make generating the genealogy data
a bit easier for larger systems. (Maybe that is really the only
reasonable answer at this time?)

Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 3 16:15:56 2007

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

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