Hotwire-hg - Proof-of-concept Plugin for the Mercurial version control system
Mark Williamson
This is just to announce / request comments on a little project I've
been playing around with. Over the past few days I've written a
simple Hotwire plugin that provides an enhanced interface to the
Mercurial (http://www.selenic.com/mercurial/) revision control
system. The plugin adds some new objects and renderers, making it
possible to directly do things such as:
* View, filter and otherwise manipulate the change history of the
repository
* Export streams of changesets as patches
* Annotate the traditional file objects (and renderer) with revision
control status information
* Add streams of file objects to revision control with a simple pipe
I've written up a few examples and provided download links at
http://www.cl.cam.ac.uk/~maw48/hotwire-hg/
I'll be interested to see what folks think of it, hear any
suggestions, comments as to whether this is a useful approach, etc.
Cheers,
Mark
Mark Williamson
the mercurial mailing list. Archives of the mailing list are
available here: http://www.selenic.com/pipermail/mercurial/
I'm not sure what the Mercurial people (or you, for that matter!) will
think of this as a concept, but from my perspective it was just too
cool to ignore ;-)
Colin Walters
> Hi all,
>
> This is just to announce / request comments on a little project I've
> been playing around with. Over the past few days I've written a
> simple Hotwire plugin that provides an enhanced interface to the
> Mercurial (http://www.selenic.com/mercurial/) revision control
> system. The plugin adds some new objects and renderers, making it
> possible to directly do things such as:
comments:
On a high level, I think it would probably make sense to have some
sort of abstract notion of revision control in the Hotwire core. So
for example, if you're in a Mercurial directory, Hotwire would have a
little status/modeline type thing in the bottom right that showed
which revision you were on.
Also, one thing I notice looking at your code is that the Hotwire core
really needs better support for displaying arbitrary data structures
like the tuples Mercurial seems to use.
* Ideally, you wouldn't need to define the LogEntry class yourself -
I'd try to get objects like this into the Mercurial core if you can.
(Also on an unrelated note, would be good to subclass from object)
* And I need to move the File class into the Python core so we don't
need to do this one:
FileKlass = Filesystem.getInstance().fileklass
class HgFile(FileKlass):
* What do you think about calling them all hg-foo instead of hgfoo?
The "-" character should help us more clearly manage the namespace in
the future.
* What's the purpose of the completers you're defining? Wouldn't we
want to just use the default token completer which will give us file
path completions?
* I seem to be missing a module:
File "/home/walters/.hotwire/plugins/hg.py", line 17, in <module>
from mercurial import ui, hg, dispatch, cmdutil, util, patch
ImportError: cannot import name dispatch
Is mercurial-0.9.4-8.fc8 too old?
What would you think about maintaining these plugins in the Hotwire
SVN? I'd like to use them as a test case for cleaning up some parts
of the Hotwire core.
Kevin Kubasik
for this framework so we can take advantage of this type of stuff in
bzr, svn, git etc. Once we have some consensus on what should be
abstract vs what should be implementation specific, I would be more
than willing to start working on some of the other backends.
Some cool stuff I would like to help add or see considered for an
abstract interface:
1) The native hotwire progress bar for all relevant operations
2) Some right click features for commit/add etc.
3) Integrated diff viewing with color etc. in hotwire-edit.
On Tue, Feb 12, 2008 at 12:12 PM, Colin Walters <cgwa...@gmail.com> wrote:
>
> On Feb 11, 10:19 pm, Mark Williamson <lemmingm...@gmail.com> wrote:
> > Hi all,
> >
> > This is just to announce / request comments on a little project I've
> > been playing around with. Over the past few days I've written a
> > simple Hotwire plugin that provides an enhanced interface to the
> > Mercurial (http://www.selenic.com/mercurial/) revision control
> > system. The plugin adds some new objects and renderers, making it
> > possible to directly do things such as:
>
> Awesome! This kind of thing is exactly what I'd like to see. Some
> comments:
>
> On a high level, I think it would probably make sense to have some
> sort of abstract notion of revision control in the Hotwire core. So
> for example, if you're in a Mercurial directory, Hotwire would have a
> little status/modeline type thing in the bottom right that showed
> which revision you were on.
I would love to see this type of status information as well, very
useful, I dunno how much this concept applies to mercurial, but for
something like git or svn, the current branch, or repository would be
majorly helpful as well.
>
> Also, one thing I notice looking at your code is that the Hotwire core
> really needs better support for displaying arbitrary data structures
> like the tuples Mercurial seems to use.
This would make some things easier, my only concern is that rendering
isn't super-fast as is, we might want to consider some profiling on
the current rendering system in the near future. ( I know its too
early to do anything serious, but apparently python is super-easy to
profile, if someone has experience with this it would be really nice
to have some simple numbers to make sure theres no low-hanging fruit,
or architectural bottlenecks.)
>
> * Ideally, you wouldn't need to define the LogEntry class yourself -
> I'd try to get objects like this into the Mercurial core if you can.
> (Also on an unrelated note, would be good to subclass from object)
> * And I need to move the File class into the Python core so we don't
> need to do this one:
> FileKlass = Filesystem.getInstance().fileklass
> class HgFile(FileKlass):
> * What do you think about calling them all hg-foo instead of hgfoo?
> The "-" character should help us more clearly manage the namespace in
> the future.
> * What's the purpose of the completers you're defining? Wouldn't we
> want to just use the default token completer which will give us file
> path completions?
> * I seem to be missing a module:
>
> File "/home/walters/.hotwire/plugins/hg.py", line 17, in <module>
> from mercurial import ui, hg, dispatch, cmdutil, util, patch
> ImportError: cannot import name dispatch
>
> Is mercurial-0.9.4-8.fc8 too old?
>
> What would you think about maintaining these plugins in the Hotwire
> SVN? I'd like to use them as a test case for cleaning up some parts
> of the Hotwire core.
>
>
>
> >
>
--
Kevin Kubasik
http://kubasik.net/blog
Mark Williamson
> sort of abstract notion of revision control in the Hotwire core. So
> for example, if you're in a Mercurial directory, Hotwire would have a
> little status/modeline type thing in the bottom right that showed
> which revision you were on.
Most systems use very similar abstractions, so there's probably a
great deal of infrastructure which could be shared here.
> * Ideally, you wouldn't need to define the LogEntry class yourself -
> I'd try to get objects like this into the Mercurial core if you can.
not *strictly* intended as a library for external applications to call
into, so possibly what I'm doing is just a little bit rude :-) My
understanding is that the internal interfaces are relatively stable
but there's certainly not a library-style interface guarantee.
As a result of this, there aren't particularly nice abstraction layers
for things like this; the implementation of the "status" command in hg
makes pretty much the same calls that my hgstatus command (I basically
C&Ped bits of the code with some modification). It spits it out into
a nice generic UI layer, which *does* have a clean interface, but it
doesn't make any nice objects for us to play with in Hotwire :-( We
really need an in between level of abstraction.
I'm not sure what the status is in other VCS systems. I guess this
isn't a way of working that most of them have needed to support in the
past.
I'd certainly be interested in talking to the hg upstream about maybe
providing a more generic Python API - it'd almost certainly be useful
for many other things too.
> (Also on an unrelated note, would be good to subclass from object)
> * And I need to move the File class into the Python core so we don't
> need to do this one:
> FileKlass = Filesystem.getInstance().fileklass
> class HgFile(FileKlass):
program anywhere :-) My problem, as you've probably guessed, is that
I couldn't know statically whether I should be subclassing
GnomeVfsFile, UnixFile, etc. Having more native support for "adorned"
files carrying extra information of some kind - version control being
just one example - would make life much easier.
> * What do you think about calling them all hg-foo instead of hgfoo?
> The "-" character should help us more clearly manage the namespace in
> the future.
subcommand" syntax like hg, git, svn and friends use. As far as I
could tell that's not a great fit with the Hotwire way of doing
things, so I gave up. A "-" would certainly be cleaner.
> * What's the purpose of the completers you're defining? Wouldn't we
> want to just use the default token completer which will give us file
> path completions?
was copying the example in the hotwire wiki ;-) I left them in there
on the expectation that the commands would probably want to have
completable flags / options added at some point in the future.
I didn't realise this was breaking file path completions though,
that's unfortunate and should probably be fixed!
> * I seem to be missing a module:
>
> File "/home/walters/.hotwire/plugins/hg.py", line 17, in <module>
> from mercurial import ui, hg, dispatch, cmdutil, util, patch
> ImportError: cannot import name dispatch
>
> Is mercurial-0.9.4-8.fc8 too old?
I'm using the post-0.9.5 development tree here and there were a few
restructurings in recent times I think. Hopefully longer-term some
kind of abstraction / API might be available to avoid this sort of
problem.
> What would you think about maintaining these plugins in the Hotwire
> SVN? I'd like to use them as a test case for cleaning up some parts
> of the Hotwire core.
that's useful to someone. Let me do a bit of cleanup and updating of
the copyright messages and then I could submit it for inclusion?
Cheers,
Mark
Mark Williamson
> for this framework so we can take advantage of this type of stuff in
> bzr, svn, git etc. Once we have some consensus on what should be
> abstract vs what should be implementation specific, I would be more
> than willing to start working on some of the other backends.
stuff recently and can say there is a whole ton of conceptual
commonality between all the modern DVCS systems (and they obviously
inherit a lot from the old centralised systems). So there should be
lots of worthwhile stuff to share here.
Sadly they don't always call these things by the same names. In some
cases they even use somewhat misleading names. But there's definitely
a core set of common operations (e.g. clone, push, pull, checkout,
commit, merge, log, diff, outgoing, incoming) that are directly
available or easily implemented on every system, even if they choose
to represent them in quite a strange way.
Using Hotwire for this sort of stuff is really interesting because
it's exactly the kind of place where the bytestream-oriented Unix
shell is quite unnatural and we really can get huge benefits from the
object stream approach... When I started putting together pipelines
like "hgstatus | filter image mimetype | filter unknown status |
hgadd" I really felt like I was onto something that could be usable!
> Some cool stuff I would like to help add or see considered for an
> abstract interface:
> 1) The native hotwire progress bar for all relevant operations
> 2) Some right click features for commit/add etc.
> 3) Integrated diff viewing with color etc. in hotwire-edit.
color diff viewer in hotwire itself would be generically useful, even
outside of revision control. We might want to consider a means of
make a "diff object" (even if it's really just a string) easy to
manipulate and feed into SCM commands, or generic commands like patch.
I guess something worth mentioning for the future is that all the
distributed VC systems represent their changeset history as a directed
acyclic graph. They can flatten them to a list, one way or another,
which is what I've used for "hglog". But it might be worth bearing in
mind that a DAG renderer could represent these changegraphs more
completely and would be quite reusable for the main systems (git, bzr,
hg). There's existing code out there that may be reusable.
Cheers,
Mark