Should we use subrepos ourselves?

[Martin Geisler]

Mads Kiilerich <mads at kiilerich.com> writes:

> On 08/20/2010 10:11 AM, Martin Geisler wrote:
>> However, there is one case where subrepos would make things nicer for
>> us: when the i18n repository is merged into main, we get these big
>> "junctions" when 4 lines of development is merged using 3 merges:
>>
>>    http://selenic.com/hg/graph/b9d316bcc013
>>
>> Using subrepos, we would effectively decouple the two repositories and
>> so there would be a single changeset in main when the .hgsubstate file
>> is updated. Overall this means less clutter.
>
> Yes, when we utilize the D in DVCS we get something that works fine
> but is hard to comprehend.
>
> What information is it that you would throw away?

I'm not going to throw any information away, but all the commits made in
i18n wont be visible in 'hg log' in the top level repo.

> Each revision in the i18n repo is closely related to exactly one
> revision in the Mercurial repo. While working with the i18n you would
> get exactly the same graph in your outer Mercurial repo as we see now.

No, there would only be two "tracks" in the i18n subrepo, one for
changesets on stable and one for changesets on default.

> Would you throw that outer repo away and make a "code drop" of the
> i18n repo so we got the history of i18n but without information about
> what Mercurial version they related to?

Yeah, I guess you could put it like that. I think the workflow for
translators would be this:

  $ hg clone http://selenic.com/hg/
  $ cd hg  # i18n dir is a subrepo cloned from BB
  $ make i18n/xx.po
  $ cd i18n
  # translate
  $ hg commit -m 'xx: translated stuff'
  $ hg push # push to BB i18n repository

When new changes appear in the main Mercurial repo, they do

  $ cd ..
  $ hg pull -u

to grab new stuff from selenic. This also updates their subrepository
back to whatever revision Matt last saved in the .hgsubstate file. So

  $ cd i18n
  $ hg update
  $ cd ..
  $ make i18n/xx.po
  # more translation...


I think those are the commands. I can already see that having to update
the i18n subrepo an extra time on every update of the outer repo is
annoying... here it would be handy if the outer .hgsubstate file could
say "update to tip" instead of "update to changeset X".

Maybe the translators should just make the commit at the top level and
so update the .hgsubstate file as they go along. After a pull from Matt,
they would have to merge the top level repo. These merge commits will
never be pushed anywhere, they just serve to record the state of the
i18n subrepo.

(I know this makes life harder for the translators so this will just be
a thought experiment.)

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100820/ea203328/attachment.pgp>