On Feb 3, 2005, at 5:54 AM, Roel Harbers wrote:
> Norbert Unterberg wrote:
>> Roel Harbers schrieb:
>>> Also, it seems that after this "undo", the blame info is gone: all
>>> lines were changed during the last commit.
>> Couldn't you just branch from trunk at the revision where everything
>> was good, delete trunk and move that branch to trunk? This would keep
>> the blame history intact and would not store the file a third time in
>> the repos.
>
> That sounds like a better way to undo a faulty commit. Maybe it should
> be mentioned in the book?
>
> I must say, I always saw svn merge -r100:99 as a bit of a hack to undo
> changes, particularly because the exact contents and structure already
> exist in the repository (never mind the size of the change, my example
> was indeed an extreme case. I'm talking from a purely conceptual pov
> now).
>
> After looking at the svn design document, (particularly
> http://subversion.tigris.org/files/documents/15/17/svn-
> design.html#Bubble-Up%20MethodIt ), I think it would be relatively
> easy (and extremely cheap) to just link the new item in the revision
> array to the old root dir.
That's exactly what the algorithm above accomplishes. The latest
revision tree would have a trunk/ dir that was actually a link to an
older version of the dir.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 15:20:12 2005