[PATCH 2 of 5] transaction: prevent addfilegenerator from always making backup

[FUJIWARA Katsunori]

At Sun, 11 Oct 2015 12:11:53 -0700,
Pierre-Yves David wrote:
> 
> On 10/09/2015 11:59 AM, FUJIWARA Katsunori wrote:
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> > # Date 1444416862 -32400
> > #      Sat Oct 10 03:54:22 2015 +0900
> > # Node ID b551f3883a6bb1285e83f257b81d10f11ab26341
> > # Parent  557573b9247d6bac06d253d32105acfec1253604
> > transaction: prevent addfilegenerator from always making backup
> 
> As said some long time ago I'm not a big fan of this. It do not feel 
> like it make much sense in the Transaction API and I would like to keep 
> it simple and consistent. The rollback special case does not seems 
> enough to break the rules.
> 
> As far as I understand, the reason we need this is that "rollback after 
> update" case. so:
> 
> - do we know what is using this case?

"working directory status" specific files should use it, but I don't
know other callers, yet.

If changing branch also had to be invisible to external processes
while transaction is running, it would become the next caller, though.

(you would ask me whether there are other 'backup=False' callers or
not, wouldn't you ?)

> - do we really care of keeping the BC on rollback corner case?

IMHO, restoring dirstate at rollbacking in non-"parent-gone" case
confuses end users, because content of files in the working directory
may be far from parents restored.

> - Can we achieve the same result in another way? (eg: in place hack in 
> rollback)

OK, I'll post revised one, which achieves the same result by changing
'repo.rollback()' side.


> As worse if this is really the only way to do that, we should make this 
> parament "private" and discourage its usage.
> 
> What do you think?
> 
> -- 
> Pierre-Yves David
> 

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp