RE: Copying (branch/tag), dumping, and filtering repository contents

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Neil
> Martinsen-Burrell
> Bicking, David (HHoldings, IT <David.Bicking <at>
> thehartford.com> writes:
>
> > Alright, one more time, and then I give up. I though this
> would be a
> > relatively simple question, but apparently I was wrong.
>
> It is possible to filter out deeply-nested subdirectories
> from SVN repositories.
----- <snip> ----
>
> One might desire a solution that would keep the history of
> the file that was copied from an excluded path, but then it
> would also have to keep the history of any ancestors of the
> original, excluded file and so forth. This would result in a
> filtered repository that could potentially include a great
> deal of stuff other than the filtered paths. The above
> solution avoids that problem.
>

Thank you very much for this sumary of the three versions of the
svndumpfilter alternatives. If I read this correctly, these programs
essentially truncate history at the point of "copy-in". Would it be
particularly problematic if such a program instead kept track of those
copied-in items, and changed the path of the prior versions to match the
most recent copy? I proposed this earlier
(http://svn.haxx.se/users/archive-2007-08/0435.shtml). I haven't
examined the dumpfile format in detail, but I think it can be done. I
have it on my list of ideas for when I have time to do some OSS
development. It seems to me to be a potentially valuable feature for
larger organizations that would like to keep a few choice pieces of very
large repositories at the cost of potential duplication of some
historical files.

Of course, some heuristics could be used to determine the case where
multiple streamlined paths reference the same history that is outside
the filter, streamline it into one, and "copy" that into the others.
This would reduce the incidence of "duplicate history". For
particularly large repositories where one wants to grab say six or seven
paths, a "path list file" could be referenced as a parameter to specify
the paths desired. I think this would give one exactly the desired
projects, with minimal bloat, while automagically reorganizing the
versions into desired paths. Essentially, this is a repository
reorganization and compaction.

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org