June 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Viewing MPI matrices
by Dmitry Karpeev 07 Jun '12

07 Jun '12

I guess that will work: I can print a separate header before viewing the Seq matrix. Dmitry. On Wed, Jun 6, 2012 at 7:30 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Wed, Jun 6, 2012 at 6:59 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> A better solution is to fix the parallel views for ASCII to print >> things properly with the right number of processes etc directly rather than >> calling the sequential views. > > > What about pushing a NO_HEADER attribute on the viewer before calling the > sequential view? >

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Satish Balay 07 Jun '12

07 Jun '12

On Wed, 6 Jun 2012, Satish Balay wrote: > ssh://[email protected]//home/petsc/petsc-buildsystem-dev > > Just to clarify - this is a play-repo - i.e all edits/clones should be > discarded later on. ok - rebase behaves differently with subrepos. How is it supporsed to work? With separate repos - I can do: hg commit [local changes] hg pull --rebase [automatically rebases the commit hg push With sub-repos - I see the following: Satish -------- [balay@maverick petsc-buildsystem-dev]$ hg version Mercurial Distributed SCM (version 2.2.1) [balay@maverick petsc-buildsystem-dev]$ hg -q in -S 23599:7c0333892302 23600:007d9928edc8 2828:1c53f750b541 2829:6548b4f26bd1 2830:03ab1f7aeb3a 2831:6ab6f1ae4aff [balay@maverick petsc-buildsystem-dev]$ hg st -S [balay@maverick petsc-buildsystem-dev]$ vi config/examples/asterix/asterix64.py config/BuildSystem/config/packages/BlasLapack.py 2 files to edit [balay@maverick petsc-buildsystem-dev]$ hg status -S M config/BuildSystem/config/packages/BlasLapack.py M config/examples/asterix/asterix64.py [balay@maverick petsc-buildsystem-dev]$ hg commit -S committing subrepository config/BuildSystem config/packages/BlasLapack.py .hgsubstate config/examples/asterix/asterix64.py committed changeset 23599:a7b4f38e3075 [balay@maverick petsc-buildsystem-dev]$ hg -q out -S 23599:a7b4f38e3075 2828:358afb29fe48 [balay@maverick petsc-buildsystem-dev]$ hg pull --rebase running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/petsc-buildsystem-dev serve --stdio' pulling from ssh://[email protected]//home/petsc/petsc-buildsystem-dev searching for changes adding changesets adding manifests adding file changes added 2 changesets with 3 changes to 2 files (+1 heads) resolving manifests getting .hgsubstate running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' pulling subrepo config/BuildSystem from ssh://[email protected]//home/petsc/BuildSystem-subrepo searching for changes adding changesets adding manifests adding file changes added 4 changesets with 4 changes to 4 files (+1 heads) resolving manifests getting config/packages/BlasLapack.py getting config/setCompilers.py getting jeff getting joe getting urlMappingLocal.py getting config/examples/asterix/asterix64.py getting makefile resolving manifests resolving manifests getting config/packages/BlasLapack.py 1 files updated, 0 files merged, 0 files removed, 0 files unresolved getting config/examples/asterix/asterix64.py abort: uncommitted changes in subrepo config/BuildSystem (use --subrepos for recursive commit) [balay@maverick petsc-buildsystem-dev]$ hg st -S M config/BuildSystem/config/packages/BlasLapack.py M config/examples/asterix/asterix64.py [balay@maverick petsc-buildsystem-dev]$ hg -q heads -R config/BuildSystem 2832:6ab6f1ae4aff 2828:358afb29fe48 [balay@maverick petsc-buildsystem-dev]$ hg -q heads 23601:007d9928edc8 23599:a7b4f38e3075 [balay@maverick petsc-buildsystem-dev]$

1 0

Re: [petsc-dev] Use of PETSc in real-time applications
by Shri 07 Jun '12

07 Jun '12

Thanks Aron. On Jun 6, 2012, at 5:43 PM, Aron Ahmadia wrote: > A. J. Ahmadia and B. L. Ellerbroek, " A Software Framework for Fast > Adaptive Optics Control with Atmospheric Tomography," > > http://www.opticsinfobase.org/abstract.cfm?URI=AO-2005-AThB4 > > On Thu, Jun 7, 2012 at 12:39 AM, Shrirang Abhyankar <abhyshr(a)mcs.anl.gov> wrote: >> Thanks Jed. >> >> On Jun 6, 2012, at 5:33 PM, Jed Brown wrote: >> >> @article{akcelik2005ddd, >> title={{Dynamic data-driven inversion for terascale simulations: real-time >> identification of airborne contaminants}}, >> author={Ak\c{c}elik, V. and Biros, G. and Draganescu, A. and Hill, J. and >> Ghattas, O. and van Bloemen Waanders, B.}, >> journal={Proceedings of the 2005 ACM/IEEE conference on Supercomputing}, >> year={2005}, >> publisher={IEEE Computer Society Washington, DC, USA} >> } >> >> On Wed, Jun 6, 2012 at 5:21 PM, Shri <abhyshr(a)mcs.anl.gov> wrote: >>> >>> Hi, >>> I'm trying to compile a list of real-time applications using PETSc. Three >>> applications are listed on the PETSc applications page. >>> >>> Computational Infrastructure for the Real-Time Patient-Specific Treatment >>> of Cancer, K. R. Diller, J. T. Oden, C. Bajaj, J. C. Browne, J. Hazle, I. >>> Babu{\vs}ka, J. Bass, L. Bidaut, L. Demkowicz, A. Elliott, Y. Feng, D. >>> Fuentes, S. Goswami, A. Hawkins, S. Khoshnevis, B. Kwon, S. Prudhomme, and >>> R. J. Stafford, University of Texas at Austin, 2008 (link broken) >>> >>> Real-Time Registration of Volumetic Brain MRI by Biomechanical Simulation >>> of Deformation during Image Guided Neurosurgery, Simon K. Warfield, Florin >>> Talos, Alida Tei, Arya Nabavi, Matthieu Ferrant, Peter McL. Black, Ferenc A. >>> Jolesz, and Ron Kikinis, Computing and Visualization in Science, 2002. (link >>> broken) >>> >>> Real-Time Biomechanical Simulation of Volumetric Brain Deformation for >>> Image Guided Neurosurgery, Simon K. Warfield, Matthieu Ferrant, Xavier >>> Gallez, Arya Nabavi, Ferenc A. Jolesz, and Ron Kikinis, Proceedings of >>> SC2000, 2000. >>> >>> Please let me know if there are any more. >>> >>> Thanks, >>> Shri >> >> >>

1 0

Re: [petsc-dev] [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 07 Jun '12

07 Jun '12

On Jun 7, 2012, at 12:39 AM, Jed Brown wrote: > On Thu, Jun 7, 2012 at 12:35 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Completely wrong. hg is magic and looks through all the source code and sees that I have referenced joe in petsc-dev and then deduces that joe must be down in BuildSystem and checks for it there and then generates a useful error message? > > It's okay for parents to manipulate their children, but not vice-versa. Children should be ignorant of their surroundings, otherwise we'll be unable to manage the complexity. So we arbitrarily pretend a graph is a tree just to make our lives easier? >

1 0

Re: [petsc-dev] [petsc-maint #119133] petsc-dev configure crash
by Jed Brown 07 Jun '12

07 Jun '12

On Thu, Jun 7, 2012 at 12:35 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Completely wrong. hg is magic and looks through all the source code and > sees that I have referenced joe in petsc-dev and then deduces that joe must > be down in BuildSystem and checks for it there and then generates a useful > error message? It's okay for parents to manipulate their children, but not vice-versa. Children should be ignorant of their surroundings, otherwise we'll be unable to manage the complexity.

1 0

Re: [petsc-dev] [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 07 Jun '12

07 Jun '12

On Jun 6, 2012, at 11:13 PM, Sean Farley wrote: > Thats not possible. If petsc-dev needed 'joe' then you would have needed to commit there (and would have either gotten an abort message about uncommitted changes or else it would be working; hence no commit necessary) Completely wrong. hg is magic and looks through all the source code and sees that I have referenced joe in petsc-dev and then deduces that joe must be down in BuildSystem and checks for it there and then generates a useful error message? The problem is real but but Jed may be right that it is a minor thing that we could live with. Barry > > On Wednesday, June 6, 2012, Barry Smith wrote: > > On Jun 6, 2012, at 9:42 PM, Satish Balay wrote: > > > On Wed, 6 Jun 2012, Barry Smith wrote: > > > >> Satish, > >> > >> You will not just "recheck this". Please setup the petsc-buildsystem-dev test repository so EVERYONE can test it and make sure there are no kinks. > > > > Added. > > > > ssh://[email protected]//home/petsc/petsc-buildsystem-dev > > Thanks > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > > This is good. > > I don't like the fact that running hg in the subrepo only affects that subrepo (because I generally just run hg in whatever strange place I am and assume it is going to do the right thing). I think running it in that subrepo directory should behave the same as outside it. For example > > If I do > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ cd config/BuildSystem/ > barry-smiths-macbook-pro:BuildSystem barrysmith$ touch joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg add joe > adding joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg commit > joe > committed changeset 2830:03ab1f7aeb3a > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > or instead do this > > barry-smiths-macbook-pro:BuildSystem barrysmith$ cd .. > barry-smiths-macbook-pro:config barrysmith$ touch BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg add BuildSystem/jeff > adding BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > barry-smiths-macbook-pro:config barrysmith$ hg commit -S > committing subrepository config/BuildSystem > jeff > .hgsubstate > committed changeset 23600:007d9928edc8 > barry-smiths-macbook-pro:config barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/petsc-buildsystem-dev > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/petsc-buildsystem-dev serve --stdio' > pushing subrepo config/BuildSystem to ssh://[email protected]//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > and then take a week vacation. In the first case if someone else does hg pull in the the petsc-dev they don't get my joe file (which may be like totally needed now to use PETSc) they get all pissed off and send me email that I don't answer for a week. (Yes they could go into BuildSystem and pull but they won't think to do that). > > Am I missing understanding something. Any option in hg to get hg commands inside the subrepo behave like ones on the outside? > > Barry > > > > > > > Just to clarify - this is a play-repo - i.e all edits/clones should be > > discarded later on. > > > > [I'm not sure how one would enforce this - and not have someone mix > > commits between this repo and the regular petsc-dev So for now its not > > available at http://] > > > > Satish > > > > --------- >

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Jed Brown 06 Jun '12

06 Jun '12

On Wed, Jun 6, 2012 at 11:00 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Am I missing understanding something. Any option in hg to get hg commands > inside the subrepo behave like ones on the outside? Can you make MatView_SeqAIJ look up the stack and figure out that it's a parallel matrix and print itself appropriately? While you're at it, maybe you can also print information about the DM and the SNES that it came from. ;-) BuildSystem is still its own repository that you can interact with without informing petsc. Think of committing from inside BuildSystem meaning that you explicitly don't want to sync with petsc-dev yet. Committing from the parent directory indicates that you do want to sync. I think this will be a rare problem and it's easy enough for the next person to fix. Certainly no worse than the current system, and the subrepo model has a bunch of other advantages.

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Satish Balay 06 Jun '12

06 Jun '12

On Wed, 6 Jun 2012, Barry Smith wrote: > > On Jun 6, 2012, at 9:42 PM, Satish Balay wrote: > > > On Wed, 6 Jun 2012, Barry Smith wrote: > > > >> Satish, > >> > >> You will not just "recheck this". Please setup the petsc-buildsystem-dev test repository so EVERYONE can test it and make sure there are no kinks. > > > > Added. > > > > ssh://[email protected]//home/petsc/petsc-buildsystem-dev > > Thanks > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > > This is good. > > I don't like the fact that running hg in the subrepo only affects that subrepo (because I generally just run hg in whatever strange place I am and assume it is going to do the right thing). I think running it in that subrepo directory should behave the same as outside it. For example > > If I do > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ cd config/BuildSystem/ > barry-smiths-macbook-pro:BuildSystem barrysmith$ touch joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg add joe > adding joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg commit > joe > committed changeset 2830:03ab1f7aeb3a > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > or instead do this > > barry-smiths-macbook-pro:BuildSystem barrysmith$ cd .. > barry-smiths-macbook-pro:config barrysmith$ touch BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg add BuildSystem/jeff > adding BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > barry-smiths-macbook-pro:config barrysmith$ hg commit -S > committing subrepository config/BuildSystem > jeff > .hgsubstate > committed changeset 23600:007d9928edc8 > barry-smiths-macbook-pro:config barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/petsc-buildsystem-dev > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/petsc-buildsystem-dev serve --stdio' > pushing subrepo config/BuildSystem to ssh://[email protected]//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > and then take a week vacation. In the first case if someone else does hg pull in the the petsc-dev they don't get my joe file (which may be like totally needed now to use PETSc) they get all pissed off and send me email that I don't answer for a week. (Yes they could go into BuildSystem and pull but they won't think to do that). Yes - all of us would have to be conscious of the subrepo model - and where we are commiting - and what hg is saying after 'hg commit'. [for ex: is .hgsubstate is updated in the commit as expected or not] And in this case where you push to only buildsytem - Jed and Peter would notice this immediately on their RSS feed and add a build-system-sync-commit to petsc-dev. [If they miss it] -folks like me would notice it when I make commits to BuildSystem - and have push errors [or use my old habbit of 'make pull'] - and then would do this build-system-sync-commit and push. Satish > Am I missing understanding something. Any option in hg to get hg commands inside the subrepo behave like ones on the outside? > > Barry > > > > > > > Just to clarify - this is a play-repo - i.e all edits/clones should be > > discarded later on. > > > > [I'm not sure how one would enforce this - and not have someone mix > > commits between this repo and the regular petsc-dev So for now its not > > available at http://] > > > > Satish > > > > --------- > >

1 0

[petsc-maint #119133] petsc-dev configure crash
by Sean Farley 06 Jun '12

06 Jun '12

Thats not possible. If petsc-dev needed 'joe' then you would have needed to commit there (and would have either gotten an abort message about uncommitted changes or else it would be working; hence no commit necessary) On Wednesday, June 6, 2012, Barry Smith wrote: > > On Jun 6, 2012, at 9:42 PM, Satish Balay wrote: > > > On Wed, 6 Jun 2012, Barry Smith wrote: > > > >> Satish, > >> > >> You will not just "recheck this". Please setup the > petsc-buildsystem-dev test repository so EVERYONE can test it and make sure > there are no kinks. > > > > Added. > > > > ssh://[email protected]//home/petsc/petsc-buildsystem-dev > > Thanks > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > > This is good. > > I don't like the fact that running hg in the subrepo only affects that > subrepo (because I generally just run hg in whatever strange place I am and > assume it is going to do the right thing). I think running it in that > subrepo directory should behave the same as outside it. For example > > If I do > > barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ cd > config/BuildSystem/ > barry-smiths-macbook-pro:BuildSystem barrysmith$ touch joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg add joe > adding joe > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg commit > joe > committed changeset 2830:03ab1f7aeb3a > barry-smiths-macbook-pro:BuildSystem barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo > serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > or instead do this > > barry-smiths-macbook-pro:BuildSystem barrysmith$ cd .. > barry-smiths-macbook-pro:config barrysmith$ touch BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg add BuildSystem/jeff > adding BuildSystem/jeff > barry-smiths-macbook-pro:config barrysmith$ hg commit > abort: uncommitted changes in subrepo config/BuildSystem > (use --subrepos for recursive commit) > barry-smiths-macbook-pro:config barrysmith$ hg commit -S > committing subrepository config/BuildSystem > jeff > .hgsubstate > committed changeset 23600:007d9928edc8 > barry-smiths-macbook-pro:config barrysmith$ hg push > pushing to ssh://[email protected]//home/petsc/petsc-buildsystem-dev > running ssh petsc(a)petsc.cs.iit.edu 'hg -R > /home/petsc/petsc-buildsystem-dev serve --stdio' > pushing subrepo config/BuildSystem to ssh:// > petsc(a)petsc.cs.iit.edu//home/petsc/BuildSystem-subrepo > running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo > serve --stdio' > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > searching for changes > 1 changesets found > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 1 changesets with 1 changes to 1 files > > and then take a week vacation. In the first case if someone else does > hg pull in the the petsc-dev they don't get my joe file (which may be like > totally needed now to use PETSc) they get all pissed off and send me email > that I don't answer for a week. (Yes they could go into BuildSystem and > pull but they won't think to do that). > > Am I missing understanding something. Any option in hg to get hg commands > inside the subrepo behave like ones on the outside? > > Barry > > > > > > > Just to clarify - this is a play-repo - i.e all edits/clones should be > > discarded later on. > > > > [I'm not sure how one would enforce this - and not have someone mix > > commits between this repo and the regular petsc-dev So for now its not > > available at http://] > > > > Satish > > > > --------- > >

1 0

Re: [petsc-dev] Fwd: [petsc-maint #119133] petsc-dev configure crash
by Barry Smith 06 Jun '12

06 Jun '12

On Jun 6, 2012, at 9:42 PM, Satish Balay wrote: > On Wed, 6 Jun 2012, Barry Smith wrote: > >> Satish, >> >> You will not just "recheck this". Please setup the petsc-buildsystem-dev test repository so EVERYONE can test it and make sure there are no kinks. > > Added. > > ssh://[email protected]//home/petsc/petsc-buildsystem-dev Thanks barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ hg commit abort: uncommitted changes in subrepo config/BuildSystem (use --subrepos for recursive commit) This is good. I don't like the fact that running hg in the subrepo only affects that subrepo (because I generally just run hg in whatever strange place I am and assume it is going to do the right thing). I think running it in that subrepo directory should behave the same as outside it. For example If I do barry-smiths-macbook-pro:petsc-buildsystem-dev barrysmith$ cd config/BuildSystem/ barry-smiths-macbook-pro:BuildSystem barrysmith$ touch joe barry-smiths-macbook-pro:BuildSystem barrysmith$ hg add joe adding joe barry-smiths-macbook-pro:BuildSystem barrysmith$ hg commit joe committed changeset 2830:03ab1f7aeb3a barry-smiths-macbook-pro:BuildSystem barrysmith$ hg push pushing to ssh://[email protected]//home/petsc/BuildSystem-subrepo running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' searching for changes 1 changesets found remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files or instead do this barry-smiths-macbook-pro:BuildSystem barrysmith$ cd .. barry-smiths-macbook-pro:config barrysmith$ touch BuildSystem/jeff barry-smiths-macbook-pro:config barrysmith$ hg add BuildSystem/jeff adding BuildSystem/jeff barry-smiths-macbook-pro:config barrysmith$ hg commit abort: uncommitted changes in subrepo config/BuildSystem (use --subrepos for recursive commit) barry-smiths-macbook-pro:config barrysmith$ hg commit -S committing subrepository config/BuildSystem jeff .hgsubstate committed changeset 23600:007d9928edc8 barry-smiths-macbook-pro:config barrysmith$ hg push pushing to ssh://[email protected]//home/petsc/petsc-buildsystem-dev running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/petsc-buildsystem-dev serve --stdio' pushing subrepo config/BuildSystem to ssh://[email protected]//home/petsc/BuildSystem-subrepo running ssh petsc(a)petsc.cs.iit.edu 'hg -R /home/petsc/BuildSystem-subrepo serve --stdio' searching for changes 1 changesets found remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files searching for changes 1 changesets found remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files and then take a week vacation. In the first case if someone else does hg pull in the the petsc-dev they don't get my joe file (which may be like totally needed now to use PETSc) they get all pissed off and send me email that I don't answer for a week. (Yes they could go into BuildSystem and pull but they won't think to do that). Am I missing understanding something. Any option in hg to get hg commands inside the subrepo behave like ones on the outside? Barry > > Just to clarify - this is a play-repo - i.e all edits/clones should be > discarded later on. > > [I'm not sure how one would enforce this - and not have someone mix > commits between this repo and the regular petsc-dev So for now its not > available at http://] > > Satish > > ---------

1 0