> -----Original Message-----
> From: David Weintraub [mailto:qazwart_at_gmail.com]
> Sent: Thursday, May 14, 2009 4:41 PM
> To: Bolstridge, Andrew
> Cc: users_at_subversion.tigris.org
> Subject: Re: How to avoid cluttering the svn repository with several
> versions of compiled files
[snip]
> > Instead I'm hoping svn obliterate will appear sooner rather than
> later
> > and fix this problem for everyone :)
>
> The problem is that this issue is much more difficult to fix than you
> might realize.
>
> You make five file changes in revision #4556: one.gif, two.gif,
> three.gif, four.txt five.txt. Don't worry about the actual
> implementation. Think about these questions.
>
> * I want to remove two.gif at revision #4556. What about the other
> four files? Should I be forced to remove the entire revision, or can I
> simply remove on revision? What would svn log look like? What if
> there's a branch or tag that the revision depends upon? Remember in
> Subversion tags live forever even after they're deleted. How is a tag
> that uses that particular revision of the file affected?
>
> * If I delete revision two.gif at revision #4556, should these changes
> be merged into revision #4557? Probably not. What about four.txt? If I
> delete that, should those changes be placed into four.txt in revision
> 4557? Probably yes.
>
Personally, I would just replace the contents of that file's revision
delta (the deltas would just have the re-calculated from the next to the
previous revision - ie. If I have 3 revs, I obliterate rev 2, the delta
that used to be 3->2 is recalculated as 3->1 and stored in rev3's file,
and rev2's file becomes a delta of "no changes")
If you obliterate the contents of a tag's HEAD revision whilst removing
revisions from the original trunk, then that's your lookout - you'll now
see the wrong (ie the previous) revision - but that's what happens when
you delete data, you have to know what you're doing.
Obliterating contents that have subsequently changed in a branch or tag
may need to be obliterated there as well. (ie I commit customer data,
then branch the file and edit it. I now have to obliterate the original
and the branched revisions... I think.. maybe the recalculation of
deltas on the original file would handle that)
I'd also append to the log (or more likely add a property) to the
revision to note the files that were obliterated, by whom and when.
You'd still see all the change histories (unless there was an option to
ignore revisions that were now empty), your disk space would be reduced,
and confidential 'whoops I added that file' mistakes would be easily
corrected.
If you wanted to only keep the latest version of a file, you could put
the command in a post-commit hook to obliterate the last-but-x revision
(so you'd only ever have the latest x versions).
It's a tricky situation to get perfectly right, as you say, but
something that does the big requirements (confidential data and disk
usage) would satisfy nearly everyone. Unless I've got this completely
wrong in my thinking.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2259940
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-14 18:45:40 CEST