0

I am looking at the mercurial guestrepo extension and I cannot truly determine what exactly it provides over simply instantiating repositories nested in each other (i.e NOT defined as subrepos).

The only plus seems that with a single single command operations (e.g. push/pull) can be executed on each guest repo (and its guests in turn) rather than doing it individually for each nested repo.

Guestrepo does not allow the "host repo" track any local changes made in the guest repo possibly leading to inconsistent code state between "host repo" and locally modified guest repo.

Am I understanding the scope of this extension correctly? What are the use cases for this extension. The documentation is too abstract for me on this point.

ARF
  • 7,420
  • 8
  • 45
  • 72

1 Answers1

0

I cannot truly determine what exactly it provides over simply instantiating repositories nested in each other (i.e NOT defined as subrepos).

  1. You miss the point - guestrepos ARE NOT just "nested repos", they are tracked by parent repo at the same style as subrepos
  2. Guestrepo is more "Configuration management", than subrepos (which, in turn, are more "Structure management", than anything more)
  3. Guestrepo is "Subverpos on steroids" in short words

Guestrepo does not allow the "host repo" track any local changes made in the guest repo

Wrong. You just have to monitor changes and do it by hand only when needed, not when committed anything in subrepo, contrary to vanilla subrepo (read about hg grstate|hg grfreeze commands) - and this is intended behavior - guestrepo (again) is more about monitoring configuration, than state (i.e any changes in guestrepos are irrelevant until they are not approved) - something like PEG-ed externals (guestrepo) in Subvervsion vs not PEG-ed (subrepo), if you understand what I'm talking about (while guestrepo can, if needed, use both style - cset-id in .hgguestrepo can be symbolic name /different csets over time/, not only hash)

Am I understanding the scope of this extension correctly? Unfortunately - no. To be more precise: almost completely wrong

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110