From: <fwi...@gm...> - 2011-03-09 20:42:41
|
Hi all, I should have posted this earlier: Alex Grönholm ran a conversion of our svn repo to hg and I uploaded it as a test. To clone it: anonymous access: hg clone http://jython.hg.sourceforge.net/hgroot/jython/test/ committers should be able to do: hg clone ssh://you...@jy.../hgroot/jython/test/ I am not an hg expert - so if folks who are could check to see that the branches, tags and history look good (note sandbox was deliberately excluded) -Frank |
From: Philip J. <pj...@un...> - 2011-03-10 17:46:29
|
On Mar 9, 2011, at 3:42 PM, fwi...@gm... wrote: > Hi all, > > I should have posted this earlier: Alex Grönholm ran a conversion of > our svn repo to hg and I uploaded it as a test. To clone it: > > anonymous access: > > hg clone http://jython.hg.sourceforge.net/hgroot/jython/test/ > > committers should be able to do: > > hg clone ssh://you...@jy.../hgroot/jython/test/ > > I am not an hg expert - so if folks who are could check to see that > the branches, tags and history look good (note sandbox was > deliberately excluded) We'll also need to apply an authors file mapping. It looks like Dirkjan has already composed one for us, I've forked his repo to update it, my latest version is here: https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-authors.txt All committers, please double check this list and email me directly if you have a correction. I suppose we could use an updated email address for Jim Hugunin =] -- Philip Jenvey |
From: Philip J. <pj...@un...> - 2011-03-11 19:27:44
|
On Mar 10, 2011, at 12:16 PM, Philip Jenvey wrote: > > On Mar 9, 2011, at 3:42 PM, fwi...@gm... wrote: > >> Hi all, >> >> I should have posted this earlier: Alex Grönholm ran a conversion of >> our svn repo to hg and I uploaded it as a test. To clone it: There's another thing we should at least consider for the conversion: what do we think about splitting out the different sub projects we have in svn into separate repos? I.e. splitting the htdocs (the old website), website (the new website), installer and the jython code base into their own separate hg repositories. -- Philip Jenvey |
From: Alan K. <jyt...@xh...> - 2011-03-12 12:50:17
|
[Philip] > There's another thing we should at least consider for the conversion: what do we think about splitting out the different sub projects we have in svn into separate repos? > > I.e. splitting the htdocs (the old website), website (the new website), installer and the jython code base into their own separate hg repositories. This is a very good idea. Our repo is too monolithic at the moment. Now that we're moving a different basis for managing the code base, if we split out the non-code stuff into separate repos, we can have greater granularity on commit rights, e.g. we'll be able to give rights for maintaining the website without giving rights to modify the jython code base, etc, which might help attain greater community participation. +1 Alan. |
From: Nicholas R. <nj...@il...> - 2011-03-11 21:01:23
|
In article <8ED...@un...>, Philip Jenvey <pj...@un...> wrote: > I.e. splitting the htdocs (the old website), website (the new website), > installer and the jython code base into their own separate hg repositories. +1, definitely. There could also be another repo with subrepositories for tagging, etc. (http://mercurial.selenic.com/wiki/Subrepository). -- Nicholas Riley <nj...@il...> |
From: Josh J. <jun...@gm...> - 2011-03-11 21:50:58
|
I also like this idea. +1 Josh Juneau jun...@gm... http://jj-blogger.blogspot.com http://www.jythonpodcast.com Twitter ID: javajuneau On Mar 11, 2011, at 3:00 PM, Nicholas Riley <nj...@il...> wrote: > In article <8ED...@un...>, > Philip Jenvey <pj...@un...> wrote: > >> I.e. splitting the htdocs (the old website), website (the new website), >> installer and the jython code base into their own separate hg repositories. > > +1, definitely. There could also be another repo with subrepositories > for tagging, etc. (http://mercurial.selenic.com/wiki/Subrepository). > -- > Nicholas Riley <nj...@il...> > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Alan K. <jyt...@xh...> - 2011-03-12 13:00:58
|
[Frank] > I should have posted this earlier: Alex Grönholm ran a conversion of > our svn repo to hg and I uploaded it as a test. To clone it: > > anonymous access: > > hg clone http://jython.hg.sourceforge.net/hgroot/jython/test/ > > committers should be able to do: > > hg clone ssh://you...@jy.../hgroot/jython/test/ Yay, the move to Mercurial has begun. Alex, thanks for your work on the conversion. Please can someone link to some good educational resources for Mercurial? I'm a newbie to using it. Since we're likely to be interacting with the cpython repo as well, some info on how cpython use mercurial would be most helpful. Thanks, Alan. |
From: Josh J. <jun...@gm...> - 2011-03-12 15:00:47
|
Alan/All- You can read Mercurial: The Definitive Guide online - http://hgbook.red-bean.com/read/, it is an excellent resource! Josh Juneau jun...@gm... http://jj-blogger.blogspot.com http://www.jythonpodcast.com Twitter ID: javajuneau On Mar 12, 2011, at 7:00 AM, Alan Kennedy <jyt...@xh...> wrote: > [Frank] >> I should have posted this earlier: Alex Grönholm ran a conversion of >> our svn repo to hg and I uploaded it as a test. To clone it: >> >> anonymous access: >> >> hg clone http://jython.hg.sourceforge.net/hgroot/jython/test/ >> >> committers should be able to do: >> >> hg clone ssh://you...@jy.../hgroot/jython/test/ > > Yay, the move to Mercurial has begun. Alex, thanks for your work on > the conversion. > > Please can someone link to some good educational resources for > Mercurial? I'm a newbie to using it. > > Since we're likely to be interacting with the cpython repo as well, > some info on how cpython use mercurial would be most helpful. > > Thanks, > > Alan. > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Raghuram D. <dra...@gm...> - 2011-03-14 14:37:59
|
On Sat, Mar 12, 2011 at 8:00 AM, Alan Kennedy <jyt...@xh...> wrote: > > Please can someone link to some good educational resources for > Mercurial? I'm a newbie to using it. > > You may want to try http://hginit.com/. Thanks, Raghu |
From: Philip J. <pj...@un...> - 2011-03-21 01:02:48
|
Hg migration updates: I spoke to Brodie Rao (whom was incredibly helpful) @ PyCon for some advice. Like Dirkjan, he highly recommended we make the move via the hgsubversion, even though it's been giving us problems, because it produces a better conversion. I think I've made some progress with it. So far I have a repo converted via hgsubversion, via these steps: a) all the scripts and mappings I'm using are in: https://bitbucket.org/pjenvey/pyimgr this repo is a fork of the files used for the cpython conversion. Our files are prefixed with jython-. It contains an updated authors mapping, a master jython-convert.sh script that does the conversion, and a preliminary branch/tags mapping b) mirror the svn repo from sourceforge: cd pyimgr; rsync -av jython.svn.sourceforge.net::svn/jython/* jython-svn c) convert subversion to hg via hgsubversion: ./convert-jython.sh 1) This runs a first pass via hgsubversion and excludes one file: sandbox/tobias/.hg. Without that exclusion, after hg subversion conversion has finished, you'd receive a "abort: path 'sandbox/tobias/.hg/hgrc' is inside repo 'sandbox/tobias'" message when trying to do the initial 'hg up'. I don't know enough about the original issue blocking the hgsubversion process (all I know is from: https://bitbucket.org/durin42/hgsubversion/issue/115/jython-repository-goes-haywire ) but I believe Frank had mentioned the issue was basically triggered by our sandbox. Is the '.hg/hgrc is inside repo' message a symptom of the original problem? The exclude workaround seemed easy enough, am I missing something else about that original issue? Anyway we're splitting the sandbox out of the repo in the next pass, so excluding anything in there is really of no consequence. 2) then convert-jython.sh runs a second pass via plain hg convert to split out the source code from the other repos. the filemap it uses: exclude htdocs exclude installer exclude sandbox exclude website rename jython . d) Finally, shrink the repo via the shrink extension (in mercurial's contrib dir) on the final repo -- Philip Jenvey |
From: Philip J. <pj...@un...> - 2011-03-21 01:06:53
|
Here's some other things we need do/consider before the conversion: a) What other repos do we want to split out? Where to host them? htdocs installer jython sandbox website I'm working on just splitting 'jython' out into its own right now. That will definitely be hosted @ http://hg.python.org (and mirrored to bitbucket). Then we'll need installer, then website? I believe htdocs is the old website, do we need this split out into an hg repo? If we can split the sandbox out successfully, where to host it, just on bitbucket? b) We might as well close any branches that may have been mistakenly left open: Release_2_2maint/ Release_2_3maint/ Release_2_5maint/ advanced/ *should be closed? (Tobias's) ctypes-jffi/ *should be closed? (Wayne's) ctypes-via-rawffi/ *should be closed? (Wayne's) customizable-proxymaker/ (Charlie's, don't think it was ever merged) indy/ ? jy26/ jy3k/ newstr/ pbcvm/ *should be closed? (jimbaker's) unicodedata/ *should be closed? (jimbaker's) c) I think we should rename branches and tags while we're here, might as well just match CPython's format: (Rename the 3 maintenance branches): https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-branchmap.txt (Make our tag format consistent with CPython's): https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-tagmap.txt d) Finally, we may want to consider splitting out some of the old feature branches into a separate, archive'd history repo. CPython did this, I assume they mostly did it to save space in the main repo. I'm not sure space is a big concern for our repo, but it is nice how clean cpython's hg repo is (branch and tag-wise). Going forward, CPython is recommending feature branches generally be separate (cloned) repos, which you'd then push a clean changeset from to the main repo when finally integrating the feature. Which means CPython's repo will only likely contain maintenance release branches going forward. Here's all the tags/branches in my current test repo: $ hg branches -c default 6362:ca2980e3ecaa 2.5 6320:3ececd2220a0 ctypes-jffi 6091:7fded7efebd8 indy 6025:6c8c4d8d47cd customizable-proxymaker 5928:4e88baaf31c3 jy26 5873:2f4ea2a32c8c newstr 5644:527eae5bdec7 unicodedata 5642:2de2e96863d8 2.2 5531:40c3c9081eb2 ctypes-via-rawffi 5468:0204cdc10bc9 jy3k 5306:2a31732bac98 2.3 5305:aa81b467355e pbcvm 5234:2d4299f0291d advanced 4729:6bb13922d8ba jsr223 5722:be2acdd1a9d3 (closed) newlist 5481:43a01d5b8ef4 (closed) modjy 5480:f47148ea8eb5 (closed) astwrite 4959:6394084f1e77 (closed) newstyle-java-types 4952:4c3cc86b387f (closed) jythonc 4836:92e591fcef27 (closed) nowalker 4557:4f48791aaac9 (closed) installer25 4555:572d3c7237e1 (closed) asm 4460:cdd9d4a56c41 (closed) pep352 4428:36ffebc540a8 (closed) august-boulder-sprint 4015:0b35a9c888e0 (closed) utf16 4013:dfa1b957e94f (closed) py25 3682:29fcb157d0cf (closed) asm_compiler 3570:fdb805db3c87 (closed) antlr 3569:8be6d3ee7dd5 (closed) modern 3420:1207532da390 (closed) newcompiler 3365:53e374cfc190 (closed) exposed_annotation 3293:403dcb913421 (closed) pyfile-nio 3162:90867abe0b6c (closed) unlabeled-1.1.2 2940:fb76fcaddb07 (closed) 2.0 2939:684f5ae18105 (closed) newstyle-branch 2938:520c8ea75eb3 (closed) pep302 2936:68220712d620 (closed) collections-integration 2935:60fa7da141a2 (closed) $ hg tags tip 6362:ca2980e3ecaa v2.5.2 6316:a24bc22d977b v2.5.2rc4 6310:0f19b2d17c05 v2.5.2rc3 6295:f88e480b1dda v2.5.2rc2 6278:97d07b32cde2 v2.5.2rc1 6270:52d62f3dc27f v2.5.2b2 6240:6c13f9c91f10 v2.5.2b1 6192:ca85b7b7cf3e v2.5.1 5939:1df05569cfe9 v2.5.1rc3 5935:77b7d9af1936 v2.5.1rc2 5926:bfbc66abd323 v2.5.1rc1 5880:383559c14e42 v2.5.0 5634:8369944bbb59 v2.5rc4 5630:89d46c90300d v2.5rc3 5555:9b469299a89d v2.5rc2 5512:fee9c0f2b86c v2.5rc1 5509:daed0c8aa304 v2.5b4 5442:1d52d3604a68 v2.5b3 5274:00c89786a430 v2.5b2 5265:2dabb16fb94a v2.5b0 4973:dfb60f518108 v2.5a3 4562:944af4a0290e v2.5a2 4544:c21eabdbce2b v2.5a0 4201:062fe1772d83 v2.2.1 3088:7d3b5ccf0d92 v2.2.1rc2 3058:e9ac95ccf403 v2.2 2958:0c5440c5aa88 cli-1-0 2407:b6cb43984e76 v2.2a1 2360:f66e1ff773dc v2.2a0 2352:ef6fe14ab6ab post-pep302-merge 2337:ec16a1548e5d pre-pep302-merge 2334:46f730d0874a post-collections-merge 2304:dcc045a0937d pre-collections-merge 2299:6a965d229745 Root_collections-integration 2258:3f5279b5ad9b pep302-pre 2238:bb56f7e0e07d pre-new-style-merge 2218:7ce10d6bc5fe merged-to-newstyle 2194:57860ac86867 newstyle-fork 2184:79e396e117c6 v2.1 1875:9f49e5d36bc0 v2.1b2 1860:54ae0bf26906 v2.1b1 1793:c713c59dcd40 v2.1a3 1620:1e2fc93830b2 v2.1a2 1574:4cf31ac09db3 v2.1a1 1476:1ad58ac2e3ff v2.0 1320:36600be60dba v2.0rc1 1304:790ee44ba3a7 v2.0b2 1290:f9318e3cdcc9 v2.0b1 1279:761e4c1a73cd v2.0a3 1269:ed1dee4ca4bb v2.0a2 1246:2d51e91cc869 v2.0a1 1160:9d6f985df65d v1.1rc1 880:80c46193e666 v1.1b4 825:a883e61bffa9 v1.1b3 752:f09f36d67664 v1.1b2 656:29edd4386a3b v1.1b1 589:b66850a5c108 Hugunin_Final_Checkpoint 303:b2d45c085bde e) Finally we also need to think about how to replace our svn:externals to CPythonLib. We could utilize subrepos for this. However if we were to subrepo CPython's mercurial repo, we would end up having to clone the entire repo (because hg doesn't allow you to clone just a subdirectory (like Lib) of a repo). When CPython splits the stdlib into its own repo, then subrepo'ing that will work great for us. But that hasn't happened yet. The path to least resistance here might be to have a subversion subrepo (subrepo would actually fork svn to go checkout CPythonLib, just like it does now). The downside there is you'd need both hg + svn installed to clone our repo, but this would only be a stopgap until the stdlib repo is split out (hopefully this happens some time in the next year). -- Philip Jenvey |
From: Wayne M. <wme...@gm...> - 2011-03-21 20:44:14
|
On 21 March 2011 11:06, Philip Jenvey <pj...@un...> wrote: > ctypes-jffi/ *should be closed? (Wayne's) > ctypes-via-rawffi/ *should be closed? (Wayne's) Those two can be closed. It was all merged into trunk. |
From: Oti <oh...@gm...> - 2011-03-21 22:51:23
|
Philipp, first of all thanks a lot for your (and brodie's) work on the hg migration!! On Mon, Mar 21, 2011 at 2:06 AM, Philip Jenvey <pj...@un...> wrote: > > Here's some other things we need do/consider before the conversion: > > a) What other repos do we want to split out? Where to host them? > > htdocs > installer > jython > sandbox > website > > I'm working on just splitting 'jython' out into its own right now. That will definitely be hosted @ http://hg.python.org (and mirrored to bitbucket). Then we'll need installer, then website? I believe htdocs is the old website, do we need this split out into an hg repo? If we can split the sandbox out successfully, where to host it, just on bitbucket? I think we really need installer and website besides jython itself. No problem for me if these are 3 repositories, but if i can wish i'd like to have them 'close' to each other. > b) We might as well close any branches that may have been mistakenly left open: > > Release_2_2maint/ > Release_2_3maint/ > Release_2_5maint/ > advanced/ *should be closed? (Tobias's) > ctypes-jffi/ *should be closed? (Wayne's) > ctypes-via-rawffi/ *should be closed? (Wayne's) > customizable-proxymaker/ (Charlie's, don't think it was ever merged) > indy/ ? > jy26/ > jy3k/ > newstr/ > pbcvm/ *should be closed? (jimbaker's) > unicodedata/ *should be closed? (jimbaker's) > > c) I think we should rename branches and tags while we're here, might as well just match CPython's format: > > (Rename the 3 maintenance branches): > https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-branchmap.txt > > (Make our tag format consistent with CPython's): > https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-tagmap.txt That's completely ok with me. > d) Finally, we may want to consider splitting out some of the old feature branches into a separate, archive'd history repo. CPython did this, I assume they mostly did it to save space in the main repo. I'm not sure space is a big concern for our repo, but it is nice how clean cpython's hg repo is (branch and tag-wise). > > Going forward, CPython is recommending feature branches generally be separate (cloned) repos, which you'd then push a clean changeset from to the main repo when finally integrating the feature. Which means CPython's repo will only likely contain maintenance release branches going forward. > > Here's all the tags/branches in my current test repo: > $ hg branches -c > default 6362:ca2980e3ecaa > 2.5 6320:3ececd2220a0 > ctypes-jffi 6091:7fded7efebd8 > indy 6025:6c8c4d8d47cd > customizable-proxymaker 5928:4e88baaf31c3 > jy26 5873:2f4ea2a32c8c > newstr 5644:527eae5bdec7 > unicodedata 5642:2de2e96863d8 > 2.2 5531:40c3c9081eb2 > ctypes-via-rawffi 5468:0204cdc10bc9 > jy3k 5306:2a31732bac98 > 2.3 5305:aa81b467355e > pbcvm 5234:2d4299f0291d > advanced 4729:6bb13922d8ba > jsr223 5722:be2acdd1a9d3 (closed) > newlist 5481:43a01d5b8ef4 (closed) > modjy 5480:f47148ea8eb5 (closed) > astwrite 4959:6394084f1e77 (closed) > newstyle-java-types 4952:4c3cc86b387f (closed) > jythonc 4836:92e591fcef27 (closed) > nowalker 4557:4f48791aaac9 (closed) > installer25 4555:572d3c7237e1 (closed) > asm 4460:cdd9d4a56c41 (closed) > pep352 4428:36ffebc540a8 (closed) > august-boulder-sprint 4015:0b35a9c888e0 (closed) > utf16 4013:dfa1b957e94f (closed) > py25 3682:29fcb157d0cf (closed) > asm_compiler 3570:fdb805db3c87 (closed) > antlr 3569:8be6d3ee7dd5 (closed) > modern 3420:1207532da390 (closed) > newcompiler 3365:53e374cfc190 (closed) > exposed_annotation 3293:403dcb913421 (closed) > pyfile-nio 3162:90867abe0b6c (closed) > unlabeled-1.1.2 2940:fb76fcaddb07 (closed) > 2.0 2939:684f5ae18105 (closed) > newstyle-branch 2938:520c8ea75eb3 (closed) > pep302 2936:68220712d620 (closed) > collections-integration 2935:60fa7da141a2 (closed) > > > $ hg tags > tip 6362:ca2980e3ecaa > v2.5.2 6316:a24bc22d977b > v2.5.2rc4 6310:0f19b2d17c05 > v2.5.2rc3 6295:f88e480b1dda > v2.5.2rc2 6278:97d07b32cde2 > v2.5.2rc1 6270:52d62f3dc27f > v2.5.2b2 6240:6c13f9c91f10 > v2.5.2b1 6192:ca85b7b7cf3e > v2.5.1 5939:1df05569cfe9 > v2.5.1rc3 5935:77b7d9af1936 > v2.5.1rc2 5926:bfbc66abd323 > v2.5.1rc1 5880:383559c14e42 > v2.5.0 5634:8369944bbb59 > v2.5rc4 5630:89d46c90300d > v2.5rc3 5555:9b469299a89d > v2.5rc2 5512:fee9c0f2b86c > v2.5rc1 5509:daed0c8aa304 > v2.5b4 5442:1d52d3604a68 > v2.5b3 5274:00c89786a430 > v2.5b2 5265:2dabb16fb94a > v2.5b0 4973:dfb60f518108 > v2.5a3 4562:944af4a0290e > v2.5a2 4544:c21eabdbce2b > v2.5a0 4201:062fe1772d83 > v2.2.1 3088:7d3b5ccf0d92 > v2.2.1rc2 3058:e9ac95ccf403 > v2.2 2958:0c5440c5aa88 > cli-1-0 2407:b6cb43984e76 > v2.2a1 2360:f66e1ff773dc > v2.2a0 2352:ef6fe14ab6ab > post-pep302-merge 2337:ec16a1548e5d > pre-pep302-merge 2334:46f730d0874a > post-collections-merge 2304:dcc045a0937d > pre-collections-merge 2299:6a965d229745 > Root_collections-integration 2258:3f5279b5ad9b > pep302-pre 2238:bb56f7e0e07d > pre-new-style-merge 2218:7ce10d6bc5fe > merged-to-newstyle 2194:57860ac86867 > newstyle-fork 2184:79e396e117c6 > v2.1 1875:9f49e5d36bc0 > v2.1b2 1860:54ae0bf26906 > v2.1b1 1793:c713c59dcd40 > v2.1a3 1620:1e2fc93830b2 > v2.1a2 1574:4cf31ac09db3 > v2.1a1 1476:1ad58ac2e3ff > v2.0 1320:36600be60dba > v2.0rc1 1304:790ee44ba3a7 > v2.0b2 1290:f9318e3cdcc9 > v2.0b1 1279:761e4c1a73cd > v2.0a3 1269:ed1dee4ca4bb > v2.0a2 1246:2d51e91cc869 > v2.0a1 1160:9d6f985df65d > v1.1rc1 880:80c46193e666 > v1.1b4 825:a883e61bffa9 > v1.1b3 752:f09f36d67664 > v1.1b2 656:29edd4386a3b > v1.1b1 589:b66850a5c108 > Hugunin_Final_Checkpoint 303:b2d45c085bde > > > e) Finally we also need to think about how to replace our svn:externals to CPythonLib. We could utilize subrepos for this. However if we were to subrepo CPython's mercurial repo, we would end up having to clone the entire repo (because hg doesn't allow you to clone just a subdirectory (like Lib) of a repo). > > When CPython splits the stdlib into its own repo, then subrepo'ing that will work great for us. But that hasn't happened yet. > > The path to least resistance here might be to have a subversion subrepo (subrepo would actually fork svn to go checkout CPythonLib, just like it does now). The downside there is you'd need both hg + svn installed to clone our repo, but this would only be a stopgap until the stdlib repo is split out (hopefully this happens some time in the next year). The hg + svn subrepo sounds reasonable, although i have no experience on this best wishes, Oti. |
From: <fwi...@gm...> - 2011-03-21 15:44:35
|
On Sun, Mar 20, 2011 at 6:06 PM, Philip Jenvey <pj...@un...> wrote: > Here's some other things we need do/consider before the conversion: > > a) What other repos do we want to split out? Where to host them? > > htdocs > installer > jython > sandbox > website > > I'm working on just splitting 'jython' out into its own right now. That will definitely be hosted @ http://hg.python.org (and mirrored to bitbucket). Then we'll need installer, then website? I believe htdocs is the old website, do we need this split out into an hg repo? If we can split the sandbox out successfully, where to host it, just on bitbucket? I think installer, jython, and website are enough - sandbox and installer can be left behind as a readonly svn repo. > > b) We might as well close any branches that may have been mistakenly left open: > indy/ ? This one can be closed - I may look at it again for ideas, but I don't think I'll move it forward as is. > c) I think we should rename branches and tags while we're here, might as well just match CPython's format: > > (Rename the 3 maintenance branches): > https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-branchmap.txt > > (Make our tag format consistent with CPython's): > https://bitbucket.org/pjenvey/pyimgr/src/tip/jython-tagmap.txt +1 > > d) Finally, we may want to consider splitting out some of the old feature branches into a separate, archive'd history repo. CPython did this, I assume they mostly did it to save space in the main repo. I'm not sure space is a big concern for our repo, but it is nice how clean cpython's hg repo is (branch and tag-wise). I don't know enough on this one - if you and the hg guys think it's the right thing to do, I say go for it. > Going forward, CPython is recommending feature branches generally be separate (cloned) repos, which you'd then push a clean changeset from to the main repo when finally integrating the feature. Which means CPython's repo will only likely contain maintenance release branches going forward. Sounds good. > Here's all the tags/branches in my current test repo: > $ hg branches -c > default 6362:ca2980e3ecaa > 2.5 6320:3ececd2220a0 > ctypes-jffi 6091:7fded7efebd8 > indy 6025:6c8c4d8d47cd > customizable-proxymaker 5928:4e88baaf31c3 > jy26 5873:2f4ea2a32c8c > newstr 5644:527eae5bdec7 > unicodedata 5642:2de2e96863d8 > 2.2 5531:40c3c9081eb2 > ctypes-via-rawffi 5468:0204cdc10bc9 > jy3k 5306:2a31732bac98 > 2.3 5305:aa81b467355e > pbcvm 5234:2d4299f0291d > advanced 4729:6bb13922d8ba > jsr223 5722:be2acdd1a9d3 (closed) > newlist 5481:43a01d5b8ef4 (closed) > modjy 5480:f47148ea8eb5 (closed) > astwrite 4959:6394084f1e77 (closed) > newstyle-java-types 4952:4c3cc86b387f (closed) > jythonc 4836:92e591fcef27 (closed) > nowalker 4557:4f48791aaac9 (closed) > installer25 4555:572d3c7237e1 (closed) > asm 4460:cdd9d4a56c41 (closed) > pep352 4428:36ffebc540a8 (closed) > august-boulder-sprint 4015:0b35a9c888e0 (closed) > utf16 4013:dfa1b957e94f (closed) > py25 3682:29fcb157d0cf (closed) > asm_compiler 3570:fdb805db3c87 (closed) > antlr 3569:8be6d3ee7dd5 (closed) > modern 3420:1207532da390 (closed) > newcompiler 3365:53e374cfc190 (closed) > exposed_annotation 3293:403dcb913421 (closed) > pyfile-nio 3162:90867abe0b6c (closed) > unlabeled-1.1.2 2940:fb76fcaddb07 (closed) > 2.0 2939:684f5ae18105 (closed) > newstyle-branch 2938:520c8ea75eb3 (closed) > pep302 2936:68220712d620 (closed) > collections-integration 2935:60fa7da141a2 (closed) > > > $ hg tags > tip 6362:ca2980e3ecaa > v2.5.2 6316:a24bc22d977b > v2.5.2rc4 6310:0f19b2d17c05 > v2.5.2rc3 6295:f88e480b1dda > v2.5.2rc2 6278:97d07b32cde2 > v2.5.2rc1 6270:52d62f3dc27f > v2.5.2b2 6240:6c13f9c91f10 > v2.5.2b1 6192:ca85b7b7cf3e > v2.5.1 5939:1df05569cfe9 > v2.5.1rc3 5935:77b7d9af1936 > v2.5.1rc2 5926:bfbc66abd323 > v2.5.1rc1 5880:383559c14e42 > v2.5.0 5634:8369944bbb59 > v2.5rc4 5630:89d46c90300d > v2.5rc3 5555:9b469299a89d > v2.5rc2 5512:fee9c0f2b86c > v2.5rc1 5509:daed0c8aa304 > v2.5b4 5442:1d52d3604a68 > v2.5b3 5274:00c89786a430 > v2.5b2 5265:2dabb16fb94a > v2.5b0 4973:dfb60f518108 > v2.5a3 4562:944af4a0290e > v2.5a2 4544:c21eabdbce2b > v2.5a0 4201:062fe1772d83 > v2.2.1 3088:7d3b5ccf0d92 > v2.2.1rc2 3058:e9ac95ccf403 > v2.2 2958:0c5440c5aa88 > cli-1-0 2407:b6cb43984e76 > v2.2a1 2360:f66e1ff773dc > v2.2a0 2352:ef6fe14ab6ab > post-pep302-merge 2337:ec16a1548e5d > pre-pep302-merge 2334:46f730d0874a > post-collections-merge 2304:dcc045a0937d > pre-collections-merge 2299:6a965d229745 > Root_collections-integration 2258:3f5279b5ad9b > pep302-pre 2238:bb56f7e0e07d > pre-new-style-merge 2218:7ce10d6bc5fe > merged-to-newstyle 2194:57860ac86867 > newstyle-fork 2184:79e396e117c6 > v2.1 1875:9f49e5d36bc0 > v2.1b2 1860:54ae0bf26906 > v2.1b1 1793:c713c59dcd40 > v2.1a3 1620:1e2fc93830b2 > v2.1a2 1574:4cf31ac09db3 > v2.1a1 1476:1ad58ac2e3ff > v2.0 1320:36600be60dba > v2.0rc1 1304:790ee44ba3a7 > v2.0b2 1290:f9318e3cdcc9 > v2.0b1 1279:761e4c1a73cd > v2.0a3 1269:ed1dee4ca4bb > v2.0a2 1246:2d51e91cc869 > v2.0a1 1160:9d6f985df65d > v1.1rc1 880:80c46193e666 > v1.1b4 825:a883e61bffa9 > v1.1b3 752:f09f36d67664 > v1.1b2 656:29edd4386a3b > v1.1b1 589:b66850a5c108 > Hugunin_Final_Checkpoint 303:b2d45c085bde > > > e) Finally we also need to think about how to replace our svn:externals to CPythonLib. We could utilize subrepos for this. However if we were to subrepo CPython's mercurial repo, we would end up having to clone the entire repo (because hg doesn't allow you to clone just a subdirectory (like Lib) of a repo). > > When CPython splits the stdlib into its own repo, then subrepo'ing that will work great for us. But that hasn't happened yet. > > The path to least resistance here might be to have a subversion subrepo (subrepo would actually fork svn to go checkout CPythonLib, just like it does now). The downside there is you'd need both hg + svn installed to clone our repo, but this would only be a stopgap until the stdlib repo is split out (hopefully this happens some time in the next year). We could do this or just check the whole CPythonLib into our hg repo until the split occurs. -Frank |
From: <fwi...@gm...> - 2011-03-21 15:45:29
|
On Mon, Mar 21, 2011 at 8:44 AM, fwi...@gm... <fwi...@gm...> wrote: > I think installer, jython, and website are enough - sandbox and > installer can be left behind as a readonly svn repo. I meant "sandbox and htdocs can be left behind". -Frank |
From: Philip J. <pj...@un...> - 2011-03-21 20:28:50
|
On Mar 21, 2011, at 8:44 AM, fwi...@gm... wrote: > On Sun, Mar 20, 2011 at 6:06 PM, Philip Jenvey <pj...@un...> wrote: >> b) We might as well close any branches that may have been mistakenly left open: > >> indy/ ? > This one can be closed - I may look at it again for ideas, but I don't > think I'll move it forward as is. I forgot to mention, if anyone wants to close out one of these branches, just go ahead and do it now in subversion. -- Philip Jenvey |
From: Nicholas R. <nj...@il...> - 2011-03-21 16:46:59
|
In article <AANLkTikrt9+U1Ze0OxcYt76E+d4VbViZHwvCZyZqRUb=@mail.gmail.com>, "fwi...@gm..." <fwi...@gm...> wrote: > We could do this or just check the whole CPythonLib into our hg repo > until the split occurs. The problem with doing this is that we'll end up cloning a copy of it for the rest of time... I like the idea of doing a Subversion submodule. -- Nicholas Riley <nj...@il...> |
From: <fwi...@gm...> - 2011-03-21 16:52:20
|
On Mon, Mar 21, 2011 at 9:46 AM, Nicholas Riley <nj...@il...> wrote: > In article > <AANLkTikrt9+U1Ze0OxcYt76E+d4VbViZHwvCZyZqRUb=@mail.gmail.com>, > "fwi...@gm..." <fwi...@gm...> wrote: > >> We could do this or just check the whole CPythonLib into our hg repo >> until the split occurs. > > The problem with doing this is that we'll end up cloning a copy of it > for the rest of time... I like the idea of doing a Subversion submodule. Forcing devs to have both svn and hg is not that big of a deal so yeah, if the svn subrepo is easy that's probably the best option. -Frank |
From: Philip J. <pj...@un...> - 2011-03-21 20:45:10
|
On Mar 21, 2011, at 1:55 AM, Dirkjan Ochtman wrote: > On Mon, Mar 21, 2011 at 02:02, Philip Jenvey <pj...@un...> wrote: >> 1) This runs a first pass via hgsubversion and excludes one file: sandbox/tobias/.hg. Without that exclusion, after hg subversion conversion has finished, you'd receive a "abort: path 'sandbox/tobias/.hg/hgrc' is inside repo 'sandbox/tobias'" message when trying to do the initial 'hg up'. >> >> I don't know enough about the original issue blocking the hgsubversion process (all I know is from: https://bitbucket.org/durin42/hgsubversion/issue/115/jython-repository-goes-haywire ) but I believe Frank had mentioned the issue was basically triggered by our sandbox. Is the '.hg/hgrc is inside repo' message a symptom of the original problem? The exclude workaround seemed easy enough, am I missing something else about that original issue? > > I'm not sure what the r4384 mentioned in the issue is about, but it > mentions partial branches, which should be unrelated to sandbox, and > is a different problem altogether. IIRC we fixed it at last year's > PyCon by rewriting Jython repo branching (by basically sedding an > svndump file) to make full branches instead of the partial branches > currently in the history. It's quite possible that Noah Kantrowitz' > script to do this is still available from his github account > (coderanger). Ok, I found his script: https://github.com/coderanger/misc/blob/master/fix_jython/fixjython.py Running the svn repo through this script seems to have helped another issue I spotted last night, where some branch creating commits ended up with no parent commit (or with a parent of -1:000000000000). That must have been a symptom of the incorrect partialbranch handling. > >> Anyway we're splitting the sandbox out of the repo in the next pass, so excluding anything in there is really of no consequence. >> >> 2) then convert-jython.sh runs a second pass via plain hg convert to split out the source code from the other repos. the filemap it uses: >> >> exclude htdocs >> exclude installer >> exclude sandbox >> exclude website >> rename jython . > > I wouldn't do it this way; instead, convert only jython in the first > step, and convert the others separately at the hgsubversion stage. > hg-to-hg conversion doesn't result in a canonical repository; among > other things, I think tags will no longer correctly be represented in > history. I'm confused, are you saying I should be doing one pass -- and to use the exclude/rename filemap above during the svn2hg via hgsubversion? Then what, do the same hg2svn pass again with hgsubversion, but that time instead excluding jython and including the next repo I want pulled out of there? Right now I'm having issues specifying a filemap like this to hgsubversion. For example, when 'sandbox' is excluded, and only jython is included, hgsubversion fails with the exception below. I believe the cause is a commit that copies data from the sandbox: ------------------------------------------------------------------------ r3256 | cgroves | 2007-06-17 23:17:10 -0700 (Sun, 17 Jun 2007) | 1 line Changed paths: A /trunk/jython/Lib/select.py (from /trunk/sandbox/kennedya/asynch_sockets/select.py:3255) R /trunk/jython/Lib/socket.py (from /trunk/sandbox/kennedya/asynch_sockets/socket.py:3255) A /trunk/jython/Lib/test/test_select.py (from /trunk/sandbox/kennedya/asynch_sockets/test/test_select.py:3255) A /trunk/jython/Lib/test/test_select_new.py (from /trunk/sandbox/kennedya/asynch_sockets/test/test_select_new.py:3255) R /trunk/jython/Lib/test/test_socket.py (from /trunk/sandbox/kennedya/asynch_sockets/test/test_socket.py:3255) Copy Alan's new socket and select into trunk from the sandbox ------------------------------------------------------------------------ I guess because the sandbox is excluded, hgsubversion makes this an empty commit -- there's a commit for it in the hg repo but it touches no files: (from log -v) hangeset: 3267:3c502baa200c user: Charlie Groves <cha...@gm...> date: Mon Jun 18 06:17:10 2007 +0000 description: Copy Alan's new socket and select into trunk from the sandbox 2 conversion commits later hgsubversion dies, I think what it's trying to tell me is Lib/socket.py isn't what it expects it to be: [r3256] cgroves: Copy Alan's new socket and select into trunk from the sandbox [r3257] cgroves: specify iso-8859-1 to turn the byte array into a string rather than relying on the [r3258] amak: Updated socket module to use symbolic constants from the errno module instead of raw i 12924 trunk/jython/Lib/socket.py ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.6.6 (r266:84292, Mar 17 2011, 19:12:07) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] ** Mercurial Distributed SCM (version 1.8) ** Extensions loaded: graphlog, fetch, extdiff, transplant, record, hgk, rebase, forrest, mq, hgsubversion, convert, shrink Traceback (most recent call last): File "/Users/pjenvey/src/python/hgsubversion-env/bin/hg", line 5, in <module> pkg_resources.run_script('mercurial==1.8', 'hg') File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 489, in run_script File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py", line 1207, in run_script File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/EGG-INFO/scripts/hg", line 38, in <module> mercurial.dispatch.run() File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 16, in run sys.exit(dispatch(sys.argv[1:])) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 36, in dispatch return _runcatch(u, args) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 58, in _runcatch return _dispatch(ui, args) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 601, in _dispatch cmdpats, cmdoptions) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 406, in runcommand ret = _runcommand(ui, options, cmd, d) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 655, in _runcommand return checkargs() File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 609, in checkargs return cmdfunc() File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/dispatch.py", line 598, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **cmdoptions) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/extensions.py", line 133, in wrap util.checksignature(origfn), *args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/wrappers.py", line 495, in generic return orig(ui, repo, *args, **opts) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/extensions.py", line 133, in wrap util.checksignature(origfn), *args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/hgext/mq.py", line 3047, in mqcommand return orig(ui, repo, *args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/extensions.py", line 133, in wrap util.checksignature(origfn), *args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/hgext/rebase.py", line 546, in pullrebase orig(ui, repo, *args, **opts) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/util.py", line 433, in check return func(*args, **kwargs) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/mercurial-1.8-py2.6-macosx-10.6-x86_64.egg/mercurial/commands.py", line 2940, in pull modheads = repo.pull(other, heads=revs, force=opts.get('force')) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/svnrepo.py", line 48, in wrapper return fn(self, *args, **opts) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/svnrepo.py", line 63, in pull return wrappers.pull(self, remote, heads, force) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/wrappers.py", line 325, in pull firstrun) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/replay.py", line 67, in convert_rev svn.get_replay(r.revnum, editor, meta.revmap.oldest) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/svnwrap/subvertpy_wrapper.py", line 419, in get_replay self.remote.replay(revision, oldestrev, AbstractEditor(editor)) File "/Users/pjenvey/src/python/hgsubversion-env/src/hgsubversion/hgsubversion/editor.py", line 345, in txdelt_window handler(window) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/subvertpy/delta.py", line 84, in apply_window target_stream.write(apply_txdelta_window(sbuf, window)) File "/Users/pjenvey/src/python/hgsubversion-env/lib/python2.6/site-packages/subvertpy/delta.py", line 57, in apply_txdelta_window raise AssertionError("%d != %d" % (len(tview), tview_len)) AssertionError: 13095 != 25688 -- Philip Jenvey |