Jim Correia wrote:
> 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.
Yes, I did not think of that... So, the svn merge method is always safe
but not the most efficient, while the branch solution is more efficient
and retains history better, but requires some carefulness with
concurrent use. (of course, those "lost" changes are not really lost,
merely misplaced, so a quick view of the log should reveil if these have
to be merged back in again after the undo)
Ok, that clarifies it a lot.
Personally, I would prefer the branch solution in cases where the error
in the commit is noticed quickly, because of the retained blame info.
Regards,
Roel Harbers
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 3 16:29:17 2005