Branko Cibej wrote:
> Consider your example of a "bad" comment in the code -- you do want to
> find all the versions of the file in HEAD (all branches and tags, too)
> that contain the offending text, an automated relatedness search will
> help there. But then you have to fix all those variants (perhaps by
> applying the same patch to all) and likely *not* obliterate the fixed
> versions, only the ones from your original list of relatives. An
> automated obliterate-by-bloodline would happily kill off your latest
> fixed versions in HEAD too. :)
I agree with your general analysis, as well as your comments in
following email on the great fuzziness of allowing the system to
retroactively edit a file's contents throughout its history. On that
note, I would like to point out that the functional specification
already contains the following text (from before I started messing
around with it):
"The lowest level of modification we should consider is the change
to a file or directory committed in a specific revision.
(Read: no need to support obliterating a single line in a document)"
And I think we absolutely should not allow the "modifying" history
(as contrasted with "erasing" history) use-case to enter into the
specification. (Read: no retroactive applying of patches to
non-head revisions)
> (Which raises another interesting question: what happens to object
> relatedness if you obliterate key links in the revision tree?)
Yes, this is very interesting and important.
If the obliteration does not affect the existence of a source
path_at_rev, my view is that a copy from path_at_rev should continue to
originate from the same path_at_rev. The delta needs to change, but as
subversion already allows copy+modify to occur in a single commit,
this does not seem like a problem to me.
If the existence of path_at_rev changes with obliteration (i.e. path_at_rev
disappears), then the simplest thing is to just let the copy get
converted to an add. This is what svnsync does currently in all cases,
as a former post of mine demonstrates:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1234159
That behavior could be improved in my opinion, in the following manner:
If the copy from path_at_rev becomes obsolete, but a copy from an earlier
path_at_rev in the object's history is possible (typically because it has
been copied before), then the copy should be rewritten to come from
the latest previous path_at_rev that exists in the repo.
If the copy source disappears in the obliteration, and all its prior
history is being obliterated as well, I think there is no real option
other than to convert the copy to a plain add. I've toyed around with
ideas where the copy direction would get switched so that when there
was originally an A->B copy, but then the initial part of A's history
gets obliterated so that B comes into existence first, the addition of
A would be recorded as a B->A copy. But that is just to ugly to
consider seriously (IMHO).
I do like this discussion, I feel that a lot of ambiguity about the
obliteration functionality is getting cleared up here. I realize that
we are still in the middle of a big release, but I do hope
that a level of agreement can be reached, which can then be codified
into the functional specification (I volunteer to do the
codification), and (if we are lucky) into implementation notes.
Best,
Magnus
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1263069
Received on 2009-03-03 21:51:00 CET