> On Tue, Aug 09, 2011 at 03:55:00PM -0400, Bob Archer wrote: > > > I would like to propose to add a way to abort updates in case of an > conflict. > > > This could be done by adding e.g. an abort command to the > > > interactive conflict resolution. This should transform the working > > > copy to the situation before the update that resulted in an conflict > happend. > > > > > > The reason I would like to have this is because on a project I work > > > on it regularly happens that one committer accidently reverts > > > changes made by other that result in an conflict. In this case > > > usually the easiest way to fix this is to (partially) revert the > > > conflicting commit and then update. Therefore it would be nice to be > > > able to abort an update that results in a conflict, wait for the other > commiter to revert the conflicting commit and update then. > > > > Are you sharing working copies? I'm pretty sure that is not a supported use > case for subversion... so requesting something change due to a non- > supported use case isn't going to happen. > > No. The problem results from vim failing to reload a changed document after > svn up. E.g.: > > Joe opens foo.tex with revision 1 > Jane commits revision 2 of foo.tex > Joe updates foo.tex, but vim fails to notice. > Joe changes something unrelated to Jane's commit and saves foo.tex in vim. > Joe commits revision 3 of foo.tex, which contains the contents of revision 1 > in > the section Jane is working on. > Jane changes something in her section. > Jane updates to revision 3, but this results in a conflict. > > What I would like to have is that Jane can now abort the update and ask Joe > to fix the repository contents with another commit that reverts the changes > from revision 3 so that Jane can cleanly update after Joe commited the clean > revision 4.
Ok, isn't this just a reverse merge? Also, not sure why this is on the dev list... it should be on users@s.a.o BOb
