[darcs-users] patch name suggestion

Aggelos Economopoulos aoiko at cc.ece.ntua.gr
Sun Jul 20 18:05:50 UTC 2003


On Sunday 20 July 2003 20:09, David Roundy wrote:
> On Sun, Jul 20, 2003 at 09:00:57AM -0700, Zack Brown wrote:
> > Why not put the date at the front of each patch name, in a format like
> >
> > "2003-07-20-08-46-12-The_patch_name-email at address"
> >
> > That way patches will sort chronologically in directory listings; and
> > since the date has a fixed length, the actual patch names will be easily
> > readable in that listing.
>
> Well, personally I don't find browsing the patch directory very rewarding
> in any case (among other issues, it may contain patches that aren't in the
> repo).  And when I do want to look at a patch, I usually remember the name
> better than the date.
>
> But the biggest issue is that any change to the patch name format will
> break repository compatibility, which I don't want to do unless I have a
> very good reason.  I recommend that if you want to see what patches are
> available you read the inventory file (or run the cgi script), or if you're
> running the most recent darcs you could use the darcs changes command to
> get it in a somewhat nicer format.

Any chance we could get a graphical browser? Since there are no mature haskell 
GUI libraries, how about providing hooks into darcs functions that can be 
used by other programming languages?

In the case of the patch browser, I think[1] you could get away with writing 
it in <insert a popular programming language with mature toolkits, say C/GTK 
or C++/Qt or whatever> and just duplicating the repository access functions. 
Of course this implies you'll have to keep them in sync whenever you change 
the repository format, but I think the gains outweigh the extra effort.

Going a step further: if I ever feel[2] like doing the coding, would you 
consider accepting it in the tree? I've attached a snapshot of a simple[3] 
browser I've been using for a few weeks, so that you can see what I have in 
mind.

Aggelos

[1] the dependencies seem trivial for implementing something as simple as the 
attached

[2] not unlikely but not certain either

[3] s/simple/simplistic/ . Throwaway ruby/tk code, hacked up in a few hours 
(hey, hadn't used tk before) and barely touched since.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snapshot2.png
Type: image/png
Size: 32095 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20030720/714b5be0/attachment.png 


More information about the darcs-users mailing list