Force pull from subrepos

Mina R Waheeb syncer at gmail.com
Wed Jul 15 17:29:40 CDT 2009


On Wed, Jul 15, 2009 at 8:33 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Wed, 2009-07-15 at 20:02 +0000, Mina R Waheeb wrote:
> > Here is an my workflow:
> >
> > cd toplevel
> > hg init
> > hg convert http://svn.myserver/somerepo subrepo
> > echo subrepo = subrepo > .hgsub
> > hg add .hgsub
> > cd subrepo
> > hg update # now we have the lastest tip from the converted repo
> > (mirror, read only)
> > cd ..
> > hg commit # now the .hgsubstate contains a specific version of the
> > subrepo
> > hg update null
>
> What's the update null for?


I use update null on the server side to remove the working copy and make it
easy for hgweb when scan the repos directory because i use ** in paths
section


>
>
> > ## The above commands i used to set up the main repo which everyone
> > push to it
> >
> > ## do normal clone in a dev machine
> > hg clone http://hg.myserver/toplevel # Now i have a copy
> >
> > ## I have cron job incrementally update the hg mirror daily
> > cd /path/to/toplevel/
> > hg convert http://svn.myserver/somerepo subrepo ## pull the svn
> > updates from the SVN server
> >
> > ## Now i go back to the cloned repo
> > hg pull # I got no changes because .hgsubstate is pointed to a
> > specific version
> > ## then i have to do
> > cd subrepo # and add the default push url
> > hg pull
>
> You're missing an hg up here. You seem to be objecting to the need to do
> pull and update, but this is just Mercurial-as-usual.


Sorry, i forgot that in the email, i use -u usually


>
> > cd ..
> > hg commit # this will change the .hgsubstate to the current version in
> > the local copy
>
>
> > I know the above is designed functionally for the subrepo, but I just
> > need pull from all the subrepo (the tip) not pull the current version
> > in the .hgsubstate, because not every independently commit i do in
> > subrepo i have to do changeset for it in the toplevel repo!
>
> If I'm understanding you, you're asking for something that's very
> un-Mercurial-like.
>
> A Mercurial commit is a snapshot of a repository-wide consistent state.
> When you've got subrepos, we include their state in the snapshot. A
> commit in a subrepo without a corresponding commit in the top level is a
> *non-event* from the top-level point of view. There is no record of it
> happening in the top-level history, therefore it hasn't happened.


Yes, I totally agree with you that the toplevel repo should contains the
states of the subrepos which will be very useful in tagging, but what about
the (development line, tip or trunk) which is usually the repo state. Lets
say we have MAVEN project (huge one like EJB3) we will have 8 levels
subrepos at least, if i commit in level 4 repo, I will need 4 commits to
keep the top level aware about the commit! which means we will have tons of
changesets just to keep the top level aware about the daily development!, is
that what you are saying?

In the other hand if we just mark *somehow* the subrepo to pull the tip or
branch we will get rid of tons of changesets to keep the development line
synced!, this sync is required by continues build systems and integrations
systems.


>
> > What i said about the entry (idea) in .hgsubstate, when it fullzeros
> > always pull the tip.
> > (0000000000000000000000000000000000000000   my/subrepo)
>
> This seems to be confusing two things: individual states in history and
> sets of states. The null state already has a well-defined meaning: the
> empty working directory.
>
> --
> http://selenic.com : development and support for Mercurial and Linux
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090715/c599f22d/attachment.htm 


More information about the Mercurial mailing list