Re: [glob2-devel] mercurial switch

[Kai Antweiler]

>> Is this an advantage over using extra mercurial repositorials for data?
>> If the repositorials get to big they still can be replaced by
>> syncdata/syncmaps.
>>
>> I think maps are small, because mercurial compresses its repositories.
>> I haven't tried the maps explicitly but I'm confident about this.
>> So they (or some) could easily be part of the code repository.
>
> You are right, if it works your solution is better indeed. The unclear thing 
> for me is how to mix the two reps at client side. In case of problems, we can 

Argh, I have mixed things up with patch queues in branches where this
is possible.  But we could put "data/", "maps/" and "campaigns/" in the
".hgignore" file.  And use three additional repositories.


I have investigated a lot:

* Mercurial does hard links when ever possible.  But it maintains them
  only "half".  When someone changes a file in repository A the
  hardlink becomes a copy.  If repository B changes the file in the
  same way, the file stays a copy.  So my assumptions about size where
  not correct.  Also I haven't considered the compression that
  mercurial does.


* We can kill a branch (or all "recent" revisions in branches) in
  mercurial with: "hg strip -n <revision>".  Strip removes all
  revisions that depend on <revision>, so that branch should not be
  merged into the main branch.

  Downside: If someone forgets to do this and pushs into the central
  repository the branch will be in again.  But since messing with
  history is a big issue, this could be coordinated when neccessary.


* We can use the Transplant Extension to "cherry pick":
  http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension
  This allows us to clone a repository an leave all the revisions out
  That we don't want.  The extension is part of every mercurial.
  With "hg grep <file>|grep changeset"  we can get every revision
  that commited something into <file>.

  Downside: The same as above, and this extension is not mature.


* We can make snapshots with: "hg archive -t tgz ../snapshot.tar.gz"


* We can have automatical emails send to the mailing list, when
  the data repository changes.  (If you have a mail server)



> maintain them separately and provide a script to merge them.

Like "make install"
Maybe something like "make local-install"


I'm getting tired again.
I'll continue to think about it tomorrow.
-- 
Kai Antweiler