Core support for extended status? (was Re: Integrating bfiles status with 'hg status' (proposal))

Anton Markov anton.markov at gmail.com
Thu Feb 4 16:59:00 CST 2010


Inline below.

> -----Original Message-----
> From: Wagner Bruna [mailto:wagner.bruna+mercurial at gmail.com]
> Sent: Thursday, February 04, 2010 3:07 PM
> To: mercurial-devel at selenic.com
> Cc: Anton Markov; 'Greg Ward'; 'Qi Yang'; 'Tessa Starkey'
> Subject: Core support for extended status? (was Re: Integrating bfiles
> status with 'hg status' (proposal))
> 
> Hello,
> 
> Anton Markov wrote:
> > Here are some thoughts about how 'hg bfstatus' could be integrated
> with 'hg
> > status'. For now,  I am mostly looking for feedback on the
> functionality,
> > but any suggestions on implementation are also welcome.
> >
> > Example setup:
> > $ touch bfile.bin textfile.txt
> > $ hg bfadd bfile.bin
> > $ hg add textfile.txt
> >
> > Without integration:
> >
> > $ hg status
> > A .hgfiles/bfile.bin
> > A textfile.txt
> >
> > $ hg bfstatus
> > BPA bfile.bin
> >
> > Auto-status integration would be enabled with a config file option:
> >
> > $ cat > .hg/hgrc
> > [bfiles]
> > autostatus = true
> > ^EOF
> >
> > With integration enabled:
> >
> > $ hg status
> > BPA bfile.bin
> > --A textfile.txt
> >
> > $ hg status --bfile-placeholders
> > BHA .hgfiles/bfile.bin
> > BPA bfile.bin
> > --A textfile.txt
> >
> > $ hg status --bfiles-ignore
> > A .hgfiles/bfile.bin
> > A textfile.txt
> 
> Going a bit further, extended status support could be also very useful
> for other
> entities inside a repository.
> 
> A subrepository, for instance, could have a set of flags for its
> internal state
> (say, "U" for unchanged, "P" for "clean, but at another revision", "W"
> for
> "working copy changed", "X" for "now my URL points somewhere else"),
> another for
> its files ("M" for modified files, recursively?), and so on:
> 
> $ hg status
> A file.txt
> M subrepository/modified.txt
> 
> $ hg status --extended
> A file.txt
> W subrepository
> 
> (the flags I chose are just an example, of course)
> 
> Do you think core support for extended status could be worth including?

I am not sure what you mean by "core support for extended status". 

I believe there may be changes required to Mercurial core in order to inject
the proper status flags messages, but my original intention was to keep as
much of the code in the bfiles extension as possible.

~Anton

> 
> Regards,
> Wagner
> 
> > Note that 'hg status' has a lot of options that 'hg bfstatus' does
> not have.
> > The filtering options will probably be easy to implement. Comparing
> > arbitrary revisions will be more difficult. Tracking of copies in
> bfiles is
> > not supported yet.
> >
> > Open question: should we warn the user if they use an option that is
> not
> > fully integrated with bfiles?
> >
> > I discuss the 'hg status' option integration in a bit more detail on
> > https://ucosp.fogbugz.com/default.asp?W20
> > under "Handling 'hg status' options".
> >
> >
> >
> > Thanks,
> >
> > Anton Markov
> >




More information about the Mercurial-devel mailing list