> 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_at_s.a.o
BOb
Received on 2011-08-09 22:06:40 CEST