Combining DVCS with version-stamped-assets : Is Largefiles the way to go? Or something else?

[Kastner Masilko, Friedrich]

> From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Warren Postma
> 
> I am wondering if anyone has successfully deployed "Largefiles" and is
> happy with it, or if I should roll my own two-tier binary file
> retrieval shell-script type system involving an HTTP server. My worry
> is that by not having a clean separation between "Merge Controlled
> Files" (these are checked into Mercurial) and "Built and Automatically
> Stored, and Automatically Fetched" files (these are not even checked in
> as Largefiles, but rather stored only as shell script fetch-URLs.)

We are working with largefiles here since it was called bfiles (and then kilnbfiles). IMHO it as transparent to use as it gets considering the change of pull/update network-access compared with plain Mercurial. Especially the DVCS aspect is still somewhat functional with it, a feature that I find remarkably well thought-out. It also is part of the Mercurial project now and thus well maintained. Another plus is TortoiseHg having a decent support for it.

If I understood your use-case right, I think the best approach would be to have a depot super-repository with a bin subrepo, where you put the binaries in as largefiles. The super-repository also has the source-repo as subrepo. An example layout could be:

/depot
   |
   +- /bin (subrepo)
   |    |
   |    +- /.hglf
   |         |
   |         +- app.ico
   |         +- app.exe
   |         +- lib.dll
   |
   +- /src (subrepo)
   |    |
   |    . your
   |    . sources
   |
   +- .hgsub
   +- .hgsubstate

This way your developers can work in the source-subrepo without the need to pull down binaries (not even for the current update, like with largefiles). In addition, something like a CI server can place the binaries as largefiles into the depot-repo, while concurrently marking the revision of the source they were built from. Users can just check-out the bin subrepo with the minimal content (just the .hglf stand-in files instead of the real content), then update to the appropriate revision, pulling down only the revision's binaries via largefile-mechanisms. Maintainers could clone the depot-repo to get the whole picture.

We have a similar concept running here (although not too much focussed on largefiles), and so far it worked out quite well.

Regards,
Fritz


Development Software Systems
Festo Gesellschaft m.b.H.
Linzer Strasse 227
Austria - 1140 Wien

Firmenbuch Wien
FN 38435y
UID: ATU14650108

Tel: +43(1)91075-198
Fax: 
www.festo.at

Der Inhalt dieser E-Mail und moeglicher Anhaenge sind ausschliesslich fuer den bezeichneten Adressaten bestimmt.
Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail und
moeglicher Anhaenge durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender der E-Mail in
Verbindung zu setzen, falls Sie nicht der Adressat dieser E-Mail sind sowie das Material von Ihrem Computer zu loeschen.

This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or
dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this
e-mail, please delete it and immediately notify the sender.