On Feb 3, 2005, at 6: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. Is there anything I'm overlooking here?
I think both solution overlook the fact that the repository may be
accessed by multiple users and multiple working copies.
Repos is at revision 99. You make the faulty commit at 100. The branch
"solution" or the promote 99 back to head solution will do the wrong
thing if someone else commits 101, 102, 103 etc. between the faulty
commit and the undo operation. Merge then commit will not lose changes.
Jim
---------------------------------------------------------------------
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:14:54 2005