subrepos
Scott Palmer
swpalmer at gmail.com
Wed Nov 24 07:47:29 CST 2010
There are things missing with this "test bench".
On lines 28-29 it shows sr1 and sr2 as subrepos of hgrepo, but you've left out the steps where you've added those to the .hgsub file.
On line 46 the path in the prompt indicates you are in hgrepo but the line above indicates you should be in sr3..
Could you make a complete batch file instead of the table so it is easy to run your tests and then paste the output of the same batch file verbatim? Otherwise it is too difficult to know if you've left out something important.
Scott
On 2010-11-23, at 10:47 AM, Avgoustinov, Nikolay wrote:
> Hi again,
>
> Sorry for the silence, there is much to do...
>
> I have prepared a small "test bench" to reproduce some of the errors and verified it with Mercurial 1.7.1; the lines are numbered afterwards to allow referencing, third column contains comments:
> 1.
> E:\tmp>hg init hgrepo
>
> 2.
> E:\tmp>cd hgrepo
>
> 3.
> E:\tmp\hgrepo>md sr1
>
> 4.
> E:\tmp\hgrepo>md sr2
>
> 5.
> E:\tmp\hgrepo>hg init sr1
>
> 6.
> E:\tmp\hgrepo>date /t >sr1\date
>
> 7.
> E:\tmp\hgrepo>date /t >sr2\date
>
> 8.
> E:\tmp\hgrepo>hg add sr1\date
>
> 9.
> abort: path 'sr1\\date' is inside repo 'sr1'
> Note the double backslash in this answer and the forward slash in line 13!
> 10.
> E:\tmp\hgrepo>hg add sr2\date
>
> 11.
> E:\tmp\hgrepo>hg init sr2
>
> 12.
> E:\tmp\hgrepo>hg ci -u me -m "initing sr"
>
> 13.
> abort: path 'sr2/date' is inside repo 'sr2'
> This is ok, but I am almost sure that it was not in the previous version…
> 14.
> E:\tmp\hgrepo>cd sr2
>
> 15.
> E:\tmp\hgrepo\sr2>hg ci -m initing
>
> 16.
> nothing changed
>
> 17.
> E:\tmp\hgrepo\sr2>hg add date
>
> 18.
> E:\tmp\hgrepo\sr2>hg ci -m initing
>
> 19.
> E:\tmp\hgrepo\sr2>cd ..
>
> 20.
> E:\tmp\hgrepo> hg ci -m test
>
> 21.
> abort: path 'sr2/date' is inside repo 'sr2'
> Is there need to look in sr2 if it is known to be a subrepo? I don’t think so; hg could simply ignore all paths starting with “sr2/”…
> 22.
> E:\tmp\hgrepo>hg init sr3
>
> 23.
> E:\tmp\hgrepo>echo sr3 = sr3>>.hgsub
>
> 24.
> E:\tmp\hgrepo>hg ci -m test
>
> 25.
> nothing changed
>
> 26.
> E:\tmp\hgrepo>hg add .hgsub
>
> 27.
> E:\tmp\hgrepo>hg ci -m test
>
> 28.
> committing subrepository sr1
>
> 29.
> committing subrepository sr2
>
> 30.
> committing subrepository sr3
>
> 31.
> E:\tmp\hgrepo>date /t >sr3\date
>
> 32.
> E:\tmp\hgrepo>cd sr3
>
> 33.
> E:\tmp\hgrepo\sr3>hg add date
>
> 34.
> E:\tmp\hgrepo\sr3>hg ci -m test_sr3
>
> 35.
> E:\tmp\hgrepo>cd sr3
>
> 36.
> E:\tmp\hgrepo\sr3>hg init sr3.1
> Second level sub-repo
> 37.
> E:\tmp\hgrepo\sr3>cd sr3.1
>
> 38.
> E:\tmp\hgrepo\sr3\sr3.1>date /t >>date
>
> 39.
> E:\tmp\hgrepo\sr3\sr3.1>hg add date
>
> 40.
> E:\tmp\hgrepo\sr3\sr3.1>hg ci -m test
> Committing
> 41.
> E:\tmp\hgrepo\sr3\sr3.1>date /t >>date
> Making dirty again
> 42.
> E:\tmp\hgrepo\sr3\sr3.1>cd ..
>
> 43.
> E:\tmp\hgrepo\sr3>cd ..
>
> 44.
> E:\tmp\hgrepo>hg sta
> Problem: the changes two levels deeper are not known here
> 45.
> E:\tmp\hgrepo>cd sr3
>
> 46.
> E:\tmp\hgrepo>hg sta
>
> 47.
> M date
> One level difference is not a problem
>
> Hope this helps…
>
> Kind regards
>
> Nikolay Avgoustinov
>
> -----Original Message-----
> From: Martin Geisler [mailto:mg at aragost.com]
> Sent: Tuesday, October 19, 2010 10:22 AM
> To: Avgoustinov, Nikolay
> Cc: mercurial at selenic.com; Mads Kiilerich
> Subject: Re: subrepos
>
> "Avgoustinov, Nikolay" <Nikolay.Avgoustinov at izfp.fraunhofer.de> writes:
>
> Hello
>
> > First of all, congratulations and thank you for mercurial - a very
> > interesting and useful product! Nevertheless, I am often having
> > problems with it, and would like to report some of them.
>
> Thanks :)
>
> > I am trying to manage a huge directory tree (about 20 GB) with
> > Mercurial 1.6.4 and TortoiseHG 1.1.4 as hierarchically nested
> > subrepos, distributed on at least 3-4 different computers. You can
> > imagine that I stumble pretty often upon problems, and here I'll try
> > to describe some of the most urgent...
> >
> > The most problems arise from the fact that somehow I always succeed in
> > putting files simultaneously in both a repo - say Root - and one of
> > its subrepos - say SR1. I badly miss a tool (or a possibility) for
> > correcting this situation, because the attempt "hg forget
> > SR1/<double-committed-file>" is aborted with an error...
>
> Right. I have been working on a contract the last two months with the aim to improve the subrepo functionality, in particular to make it work better across repository boundaries. So in the upcoming Mercurial 1.7 you will be able to do
>
> hg status -S a.txt SR1/b.txt
>
> where a.txt and b.txt are in different subrepos. I've also added similar support to 'hg add' and 'hg status' and made 'hg incoming' and 'hg outgoing' recursive.
>
> The 'hg forget' command was low on the priority list and was not done.
>
> > Some of the tragic consequences are:
> >
> > 1. At latest when I try to clone Root in Root2 mercurial discovers
> > the "double commit" and aborts the clone.
>
> Hmm, I'm not sure what happens here? Can you make a small test case with the exact steps needed to reproduce the situation?
>
> That would be helpful for me to know what you are seeing.
>
> > 2. When you are cloning a large repo-tree and the operation aborts
> > prematurely, there is no easy way to finish the clone and be sure
> > that everything has been cloned - after correcting the error it is
> > too late for clone (except you don't mind to delete a couple of Gigs
> > and restart from scratch) and too early for push, because hg
> > stumbles on each subrepo not yet existing at the destination...
>
> So you are cloning from your local machine to a destination? As in
>
> hg clone . ssh://server/repo
>
> ?
>
> > 3. A partially cloned repo (after abort) have (usually?) no
> > ".hgsub"-file. Now suppose the following scenario:
> >
> > a) the lack of .hgsub in Root2/SR1 is not noticed
> > b) changes are made to Root2/SR1
> > c) "hg push Root Root2"
>
> Hmm, you cannot give more than one argument to 'hg push', so I'm not sure what you are doing here?
>
> > d) update of Root2/SR1 is forgotten!
> > e) changes are made to Root2/SR1
> > f) "hg push Root2/SR1 Root/SR1"
> > g) "cd Root 2 && hg update": after this all new files/changes
> > made in step "e)" were deleted without asking for confirmation
> > in my case: this is very unexpected&unpleasant! I managed to
> > recover the deleted files due to step "c)", but this step
> > could have been skipped, so in my opinion this is a serious
> > misbehavior of hg.
>
> If we're talking about unversioned files that were deleted, then I agree that this is bad. Please make a small test case that shows what happens.
> It should give the sequence of commands needed, similar to this:
>
> http://selenic.com/hg/file/tip/tests/test-subrepo.t
>
> > I wonder, do you really need the ".hgsub"-files? They make the use of
> > hg error-prone - for instance if one creates a repo under Root, but
> > forgets to insert the respective line in the ".hgsub"-file...
> > Since HG is anyway aware of other (sub-)repos in the subdirectories,
> > it is thinkable to make it treat any subdirectory, having in turn a
> > ".hg"- subdirectory, as a subrepo.
>
> I see what you mean -- you are correct that Mercurial notices the nested repositories and skips them. However, the .hgsub file is very much needed when there is no working copy checked out. This is typical for
> servers: there you don't need a working copy, you only need the data in the .hg/ folder.
>
> You could then say that even then, one could just nest the repositories in a checkout of the null revision. But we would still need the .hgsub file since we have no access to the working copy of a remote machine.
>
> So if you do 'hg clone http://server/repo', then your local Mercurial only gets access to the revision data inside .hg on the server. Your local Mercurial cannot discover if there is a nested (sub)repository and therefore it cannot clone it.
>
> The .hgsub file also servers as the place where you declare the source URL of your subrepos. Mads and I have talked about how supporting absolute paths for subrepos sources leads to some weird situations, but the fact is that we do support them. So you cannot always expect to find the subrepos nested right within the main repository, especially if you consider Subversion subrepos -- there a working copy must be separate from the repository and so the repository cannot be nested within the main repository.
>
> > A special file (e.g., ".hgnosub") could be used to signal that a given
> > repository should not be treated as a subrepo, but as a separate
> > repository instead... Was just an idea.
>
> Perhaps you would like this extension:
>
> http://mercurial.selenic.com/wiki/HgNestedExtension
>
> As I understand it, it operates on an unstructured set of nested repositories and lets you clone/push/pull the whole group with one command.
>
> > Please, feel free to ask if I was not clear somewhere - I would be
> > glad to contribute at least with reports/recommendations to the
> > development of Mercurial.
>
> Thanks -- we need more reports from users like you, so I appreciate your feedback.
>
> --
> Martin Geisler
>
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/mercurial/
>
> Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse, dem
> Anwaltsgeheimnis unterliegende oder sonstige vertrauliche
> Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
> erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich
> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie
> die empfangene E-Mail. Vielen Dank.
>
> The information contained in this email message may be
> confidential information, and may also be the subject of legal
> professional privilege. If you are not the intended recipient,
> any use, interference with, disclosure or copying of this material
> is unauthorised and prohibited. Please inform us immediately
> and destroy the email. Thank you for your cooperation.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20101124/5cb59360/attachment-0001.htm>
More information about the Mercurial
mailing list