A Question about bfrefresh

[Anton Markov]

Inline below.

> -----Original Message-----
> From: mercurial-devel-bounces at selenic.com [mailto:mercurial-devel-
> bounces at selenic.com] On Behalf Of Marcus Lindblom
> Sent: Thursday, February 04, 2010 9:17 AM
> To: mercurial-devel at selenic.com
> Subject: Re: A Question about bfrefresh
> 
> On 2010-02-04 04:33, Greg Ward wrote:
> > The next move is of course tighter integration with core hg, which
> > means doing exactly what I just said is surprising or even evil.  But
> > it would be much less surprising if "hg status" actually reports
> >
> >    M foo
> >    A
> >    B-M bigfile
> >
> > before "hg commit" magically updates .hgbfiles/bigfile.
> >
> > In other words, auto-status mode is approximately as important as
> > auto-refresh mode.  I think they are both essential, I'm just not
> sure
> > if one must come before the other.  Offhand I think that auto-status
> > mode should come first.
> 
> Just FYI, subrepos ought to do something similar, I think.
> 
> mpm seems to want the statuses of all repos to be reported at once, so
> some kind of extra info is necessary so that other tools can determine
> what is important and not. (I submitted a simple patch for recursive
> status, and that wasn't according to plan. However, I didn't get any
> feedback on my follow-up post so I'm unsure what the proper way is).
> 
> Awyway, Bigfiles could (should?) identify itself in a similar way to
> subrepos on the output (so that tools and humans can easily differ
> what's in the repo proper and what is data handled by extensions...)

In my proposal for hg status & bfstatus integration [0], I suggest the
format
$ hg status
BPA bfile.bin
--A textfile.txt

In particular, I would add two status fields for a total of 3:
  1. The extension handling the file: '-' for built-in, 'B' for bfiles, etc.
  2. Extension-specific data
  3. The repository status of the file as defined by 'hg status'

This way other extensions like subrepos could report their own status. Of
course there is still the implementation problem of allowing different
extensions to inject status codes without stepping on each-other.


[0] http://selenic.com/pipermail/mercurial-devel/2010-February/018405.html



Thanks,
Anton

> 
> Cheers
> /Marcus
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel