2

I'm aware of the whole dump|filter|load, obliteration etc. issue. And I agree that normally you don't really have to delete files from history.

However I have what I think is a special case. For the past few years my team was working on a few iOS project, not all of them closely related, but they share some common code, and they are managed on the same svn repo.

Now the problem: the company has decided to transfer further development of one of the projects to a third party. We need to give them that project's code -- including history -- but we don't want to give them the code for the other projects.

How can I do that? For reasons documented by Svndumpsanitizer's author, the dump|filter|load cycle doesn't do the trick; unfortunately, neither does Svndumpsanitizer itself. My current approach is to migrate the repo to git, where you can delete history. But I think that's an overkill.

noamtm
  • 12,435
  • 15
  • 71
  • 107
  • 1
    Do they really need your revision history? what good is that really going to do for them? In my experience, handing off like this has never involved history, just the code as it stands at the time of hand-off. – invertedSpear Mar 20 '13 at 21:48
  • 1
    Initially we just gave them the code. They asked for the history, because "it can help understanding the code". We're trying to comply. – noamtm Mar 20 '13 at 22:07

1 Answers1

2

The official Apache Subversion FAQ entry applies to your case as far as I see ATM.

The new approach that allows you to filter repository history supposedly should help:

You can replicate the repository with svnsync tool after configuring path-based authorization rules that deny read access to any paths that need to be filtered out from repository history.

Unlike svndumpfilter, svnsync will automatically translate copy operations with an unreadable source path into normal additions, which is useful if history involving copy operations needs to be filtered.

Also check this answer: https://stackoverflow.com/a/13720677/761095.

Community
  • 1
  • 1
bahrep
  • 29,961
  • 12
  • 103
  • 150
  • Thanks. Strange that I missed that approach, but it doesn't look ideal either: I have to manually blacklist all disallowed directories. What's worse, the blacklist has to be correct for all revisions of the repo. Am I missing something? – noamtm Mar 21 '13 at 08:43
  • +1 because it's a good answer; not marking as "the" answer because it didn't solve my problem. – noamtm Aug 31 '14 at 10:53