Ivan Zhakov wrote on Mon, Sep 05, 2011 at 13:57:51 +0400: > On Mon, Sep 5, 2011 at 13:52, Stefan Sperling <s...@elego.de> wrote: > > On Mon, Sep 05, 2011 at 01:46:09PM +0400, Ivan Zhakov wrote: > >> On Mon, Sep 5, 2011 at 13:41, Stefan Sperling <s...@elego.de> wrote: > >> > On Thu, Sep 01, 2011 at 12:06:40AM +0200, Stefan Sperling wrote: > >> >> On Tue, Aug 30, 2011 at 12:43:29PM +0200, Stefan Sperling wrote: > >> >> > I'll try to tweak my proposal such that successor ID updates become > >> >> > transactional and happen as part of every commit. > >> >> > >> >> Here's a first shot at this. Comments welcome. > >> > > >> > FSFS gurus: > >> > > >> > Are any of you looking at this? > >> > Do you think this is worth writing a prototype implementation for? > >> > > >> > I have so far only received feedback from danielsh. This makes me very > >> > happy but if anyone with a couple more years of FSFS experience under > >> > their belt could comment I would be even happier. > >> > > >> I'm not FSFS guru, but I still feel that FSFS successor ID doesn't > >> worth to be implemented because there is no strong reasons/usage for > >> it. For me it looks like bottom-up design approach. > > > > Hmmm... you don't think that auto-resolving tree-conflicts involving > > moves during merges is worth implementing? > > > No, I think that auto-resolving tree-conflicts involving moves is most > important task for Subversion 1.8. But I feel it could be implemented > without implementing FSFS successor ID storage. It seems that > algorithm that you posted could be reversed. >
What do you mean by 'reversed'? > Anyway we can implement top-level part of handling moves and then > optimize it using FSFS successor ID storage or something else. > > > -- > Ivan Zhakov
