Adding comments to groups of changes?

Fri Jun 27 10:42:26 CDT 2008

Hi, 

I created a basic concept, but before I put it into code, I'd like to hear 
your opinions and suggestions. 

[Core concepts]

1) A group is similar to a tag for multiple changesets. So I want to implement 
it similarly: with a .hggroups file inside the repository which lists all 
groups. This way, groups don't pollute the store, but they get carried over 
to other repositories. 

2) As little data as possible should be stored inside that file (but as much 
as reasonable necessary or useful in future). 

3) The log should still show that the groups revisions exist, but limit them 
to one line which says, which group they are part of. A changeset can be part 
of many groups technically, but there it might get difficult to gather output 
for tools like hg view. The log should show all groups the changeset is part 
of, or not show the changeset which are in groups at all. 

[Details]

= .hggroups =

Since a group contains many changesets, they are listed at the end of the 
line, referenced by their hex and seperated by spaces. 

The groups metadata (description, author, date) is listed at the beginning of 
the line, after the group hex_value, each enclosed by single or double 
quotation marks. 

For the order of the metadata I didn't find good reasons for any special way, 
so I went by my gut: The most interesting part first. 

hex_value_of_all_deltas "description" "author" "date" changeset1 changeset2 

.hggroups example: 
group0_hex "Description" "user" "date" rev1_hex rev2_hex ...
group1_hex "Description" "user" "date" rev1_hex rev2_hex ...
group2_hex "Description" "user" "date" rev1_hex rev2_hex ...

This way .hggroups can be append only. 

Disadvantage: The metadata which groups can or must have can't be changed 
easily. 

= hg log =

Example: 

$ hg log

    changeset:   5:1a8a0fe7ab0a
    user:        Arne Babenhauserheide <bab at draketo.de>
    date:        Fri Jun 27 09:48:08 2008 +0200
    summary:     First call log when group gets started to get useful output 
while developing.

    changeset:   4:880f870098c8
    user:        Arne Babenhauserheide <bab at draketo.de>
    date:        Fri Jun 27 09:29:45 2008 +0200
    summary:     Added tag v0.0 for changeset 333aaf680223

    group:       0:some_short_hex
    tags:        v0.0 v0.1 v0.2 ...
    changesets:  1 3 
    user:        Arne Babenhauserheide <bab at draketo.de>
    date:        Fri Jun 27 09:29:45 2008 +0200
    summary:     Grouped changes summary. Displayed above the most recent 
grouped changeset. 

    changeset:   3:880f870098c8 in group 0

    changeset:   2:9db08cf8e902
    user:        Arne Babenhauserheide <bab at draketo.de>
    date:        Thu Jun 26 18:22:24 2008 +0200
    summary:     First step: Printing the REVs we want to add as group - only 
commandline parsing, no real action, yet.

[Questions]

How should I best get, combine and process the data from the changesets? What 
I see at the moment is: 
- repo.changelog.delta(rev1, rev2) returns the changes for the given revision. 
- The metadata of the group should be added, so the hash can't clash with a 
revision hash, if group and revision are the same. 

How do I create a revision_id for that? -> How do I turn deltas into a 
revision hash? 

Does the concept seem sound to you? 
What could be improved? 

(I already did some coding to try things, so this concept should work. I don't 
know if it's the most elegant solution, though). 

Best wishes, 
Arne

Am Donnerstag 26 Juni 2008 20:46:47 schrieb Arne Babenhauserheide:
> I now have a basic idea how to implement this.
>
> I'll write up a concept and post it here, then.
>
> Best wishes,
> Arne
>
> Am Donnerstag 26 Juni 2008 20:07:53 schrieb Arne Babenhauserheide:
> > Hi Benoit,
> >
> > Am Donnerstag 26 Juni 2008 16:41:40 schrieben Sie:
> > > I never heard of any feature like that in the past, but I actually also
> > > like the concept ...
> > >
> > > Looks feasible to me to implement it as an extension defining the group
> > > command and overwriting the log command showing the groups instead of
> > > the changesets if any. groups could be identified by hashes based on
> > > their sub components. Another command to inspect the content of the
> > > groups might be usefull also.
> > >
> > > Care to write a proof of concept ?
> >
> > I'll try to.
> >
> > I'm not a professional developer, though.
> >
> > But maybe we could first discuss how best to implement it.
> >
> > More exactly I currently see several interesting points:
> > 1) How can the information be stored, and how can it be implemented in
> > the log? Since a changeset is a collection of changes, can a group be
> > implemented and stored similarly? Can a group be stored as a kind of
> > changeset? Or is there already some other structure I could use?
> >
> > 2) As a group can contain merges and non-concurrent revisions, a group
> > can have more than 2 parents. More exactly: logically it has all parents
> > of changesets whose parent/-s isn't/aren't also in the group, and the
> > same is true for children. How can that be properly implemented in the
> > log to not break other commands?
> >
> > 3) Would the group command be useful, if it could only contain concurrent
> > revisions? What would happen if then someone created a new branch from
> > one of the revisions inside the group? -> one more child node. We're back
> > at 2, so restricting to concurrent revisions won't be feasible ->
> > simplistic solution rejected.
> >
> > I started a module, which doesn't yet do much, but adding the group
> > command to Mercurial:
> > -> http://freehg.org/u/ArneBab/hgext_group/
> >
> > Best wishes,
> > Arne

-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20080627/db3e7a3b/attachment.pgp 