>> 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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
