On Sat, Jan 22, 2011 at 1:27 PM, Eric Firing <ef...@ha...> wrote: > I would like to be included in the group with git write access, unless > there is a clear decision to restrict this group to a very small core of > gatekeepers. I can add you -- any developer who currently has mpl commit privs, send me your github account name and I'll add you to the mpl organization. Although a gatekeeper model may have its merits. and you'd be a gatekeeper under any scenario, I prefer to keep our current developer model of a large number of trusted committers rather than a few gatekeepers. I'd be willing to reconsider this model in the face of persuasive argument *and* a few people willing to stand up and serve as patch reviewers and gatekeepers, but until then, I think we have to rely on good people making good contributions, in the presence of our unit tests and host of people serving as crash test dummies by running off HEAD.... JDH
On Saturday, January 22, 2011, John Hunter <jd...@gm...> wrote: > On Sat, Jan 22, 2011 at 1:27 PM, Eric Firing <ef...@ha...> wrote: >> I would like to be included in the group with git write access, unless >> there is a clear decision to restrict this group to a very small core of >> gatekeepers. > > I can add you -- any developer who currently has mpl commit privs, > send me your github account name and I'll add you to the mpl > organization. Although a gatekeeper model may have its merits. and > you'd be a gatekeeper under any scenario, I prefer to keep our current > developer model of a large number of trusted committers rather than a > few gatekeepers. > > I'd be willing to reconsider this model in the face of persuasive > argument *and* a few people willing to stand up and serve as patch > reviewers and gatekeepers, but until then, I think we have to rely on > good people making good contributions, in the presence of our unit > tests and host of people serving as crash test dummies by running off > HEAD.... > > JDH > Somehow, I read that as "running with heads cut off"... It is late. Anyway, I am willing to give a switchover a shot, and to continue the current contrib model. Btw, if Friedrich hasn't been made a developer yet, he has my vote (if he wants it). Ben Root
2011年1月23日 Benjamin Root <ben...@ou...>: > Btw, if Friedrich hasn't been made a developer > yet, he has my vote (if he wants it). I feel very much honoured by this, it is a great belated Christmas gift, so I like it very much that you speak up for me, but currently I don't feel like a "core dev". Maybe, when matplotlib-filters (formerly matplotlib-grayscale) is through and committed, maybe then I'm confident enough. Best, Friedrich
On Sun, Jan 23, 2011 at 2:53 PM, Friedrich Romstedt <fri...@gm...> wrote: > I feel very much honoured by this, it is a great belated Christmas > gift, so I like it very much that you speak up for me, but currently I > don't feel like a "core dev". Maybe, when matplotlib-filters > (formerly matplotlib-grayscale) is through and committed, maybe then > I'm confident enough. I'm curious about this project -- google doesn't reveal much. As for commit privileges, my usual standard is that the candidate has become a nuisance to the other developers. That is, they are contributing patches faster than we can review them :-) That is a bit tongue in cheek, but I do like to see several patches that reveal a significant understanding of mpl internals and compliance with our coding standards. Ben's handling of several 3D bugs certainly put him in this category in my view, as this is a particularly hairy part of the code and there were not many developers who were able to review his patches because he was one of the few experts on this part of the code, and handling 3D properly means you have a pretty good grasp of the 2D stack. Friedrich hasn't become a nuisance yet <wink>. When he does, I'll be happy to add him.... JDH
On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsd...@gm...> wrote: > That said, I have the conversion routines set up right now to create a > separate "toolkits" repository, which currently includes all the > contents of trunk/toolkits. I can tailor this further to split the > toolkits up and create a repository for each, if thats how people want > to do it. Those repos could either be hosted as separate repositories > under the matplotlib github organization, or maybe better as a > repository under a separate github project. In case of the latter, I > can temporarily publish the repository at my own account, long enough > for Jeff to clone it (don't fork it using githubs fork button!) and > push it to its final destination. I think mplsize should just be moved into lib/mpl_toolkits so it can be picked up by a default mpl installation. It's small enough that it probably doesn't need it's own repo. What do you think Andrew? I think natgrid could be moved into the same directory because it is small too, but because of licensing issues I don't think it should be built and installed by default. Could you handle this move Jeff, on fairly short notice? Is there any reason basemap should not be hosted by the mpl organization? Seems like the logical place to me. JDH
On Mon, Jan 24, 2011 at 8:18 AM, John Hunter <jd...@gm...> wrote: > I think natgrid could be moved into the same directory because it is > small too, but because of licensing issues I don't think it should be > built and installed by default. Could you handle this move Jeff, on > fairly short notice? I'm going to backpedal on this one. I think including GPL code in the core distribution, even if it is disabled by default, is a bad idea. Let's go with separate repo. JDH
On Mon, Jan 24, 2011 at 9:18 AM, John Hunter <jd...@gm...> wrote: > On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsd...@gm...> wrote: > >> That said, I have the conversion routines set up right now to create a >> separate "toolkits" repository, which currently includes all the >> contents of trunk/toolkits. I can tailor this further to split the >> toolkits up and create a repository for each, if thats how people want >> to do it. Those repos could either be hosted as separate repositories >> under the matplotlib github organization, or maybe better as a >> repository under a separate github project. In case of the latter, I >> can temporarily publish the repository at my own account, long enough >> for Jeff to clone it (don't fork it using githubs fork button!) and >> push it to its final destination. > > I think mplsize should just be moved into lib/mpl_toolkits so it can > be picked up by a default mpl installation. It's small enough that it > probably doesn't need it's own repo. What do you think Andrew? > > I think natgrid could be moved into the same directory because it is > small too, but because of licensing issues I don't think it should be > built and installed by default. Could you handle this move Jeff, on > fairly short notice? > > Is there any reason basemap should not be hosted by the mpl > organization? Seems like the logical place to me. Each repository can have its own issue tracker, wiki, etc., so thats fine. But you might consider hosting documentation at github. I don't recommend using the "gh-pages branch" method of hosting docs, which uses a separate DAG in the main repository, and would serve them at http://matplotlib.github.com/matplotlib. Instead, I want to propose hosting the documentation in a repo at https:github.com/matplotlib/matplotlib.github.com.git, which will serve the sphinx-built docs at http://matplotlib.github.com . If the basemap repo is hosted under mpl, its docs could be hosted like Fernando has been suggesting, in a separate basemap-docs repo, which would be served at http://matplotlib.github.com/basemap-docs. If basemap had its own organization, the docs could be served at http://basemap.github.com. Just something to keep in mind. Darren
On Mon, Jan 24, 2011 at 9:18 AM, John Hunter <jd...@gm...> wrote: > On Mon, Jan 24, 2011 at 8:11 AM, Darren Dale <dsd...@gm...> wrote: > >> That said, I have the conversion routines set up right now to create a >> separate "toolkits" repository, which currently includes all the >> contents of trunk/toolkits. I can tailor this further to split the >> toolkits up and create a repository for each, if thats how people want >> to do it. Those repos could either be hosted as separate repositories >> under the matplotlib github organization, or maybe better as a >> repository under a separate github project. In case of the latter, I >> can temporarily publish the repository at my own account, long enough >> for Jeff to clone it (don't fork it using githubs fork button!) and >> push it to its final destination. > > I think mplsize should just be moved into lib/mpl_toolkits so it can > be picked up by a default mpl installation. It's small enough that it > probably doesn't need it's own repo. What do you think Andrew? I guess this can be done after the conversion: split it into its own repo, fix the hierarchy and then do an external merge from that repo to draw it into the matplotlib repo under lib/mpl_toolkits.
On Tue, Jan 25, 2011 at 3:06 PM, Darren Dale <dsd...@gm...> wrote: > On Tue, Jan 25, 2011 at 1:31 PM, Pauli Virtanen <pa...@ik...> wrote: >> 2011年1月25日 12:19:37 -0500, Darren Dale wrote: >>> There is a potential problem converting the entire basemap history to >>> git. In svn commit 4418, trunk/toolkits had basemap and basemap-testing >>> directories. In commit 4419, basemap was renamed basemap-0.9.6.1, so >>> there was only basemap-0.9.6.1 and basemap-testing. In commit 4420, >>> basemap-testing is renamed basemap. The git history only goes back as >>> far as svn4420, it looks like the conversion routines get confused by >>> the temporary absence of the basemap directory. >>> >>> I'm trying to find a workaround, but if I can't... ? >> >> You can maybe do it like this: >> >> 1) Write matplotlib.rules so that all of the directories where basemap >> stuff has been ends in the basemap repository. (I'm assuming this does >> not error out...) > > Aha! I thought I had tried that. Thanks. > >> 2) This will create a number of separate heads in the basemap repo that >> do not share common history. >> >> 3) Add graft rules in matplotlib.grafts to stitch the disconnected >> history graphs together. > > Mercifully, the latest checkout of svn2git seems to take care of that. > I've developed a wicked headache. > > Jeff, the repository is temporarily available at > https://github.com/darrendale/basemap . It would be really helpful if > you would have a look at the network graph at > https://github.com/darrendale/basemap/network to make sure there are > no surprises, maybe clone the repository and check that the working > directory is identical to your svn checkout. There is still an outstanding issue that must be taken care of before we migrate. The conversion routines create a basemap repository out of trunk/toolkits/basemap, and matplotlib repository out of trunk/matplotlib. Still, the matplotlib repo (at github.com/darrendale/matplotlib) is over 200 MB. One can search the objects in the large packfile, and find that there are still references to basemap data in the matplotlib repo. I don't know how it got in there, nor how to remove it. Jeff: was there ever any basemap data committed directly to trunk/matplotlib? Pauli: could I trouble you to have a look at my rules file, maybe you will notice something I overlooked? (https://github.com/darrendale/mpl2git/blob/master/matplotlib.rules) Any other ideas? Thanks Darren
On Tue, Jan 25, 2011 at 6:12 PM, Darren Dale <dsd...@gm...> wrote: > There is still an outstanding issue that must be taken care of before > we migrate. The conversion routines create a basemap repository out of > trunk/toolkits/basemap, and matplotlib repository out of > trunk/matplotlib. Still, the matplotlib repo (at > github.com/darrendale/matplotlib) is over 200 MB. One can search the > objects in the large packfile, and find that there are still > references to basemap data in the matplotlib repo. I don't know how it > got in there, nor how to remove it. I went through the exercise of identifying the largest blob, as described near the end of http://progit.org/book/ch9-7.html : $ git verify-pack -v objects/pack/pack-fa44ca56d7ec3964e562494f2fe08203143074bd.idx | sort -k 3 -n | tail -3 3b8b6c010f8ce59afac1e811b1bbc3efc21b770a blob 9154481 9089827 62749144 6328b70e665b58ed7f5aa1e110418cbb3facc07a blob 9331200 94297 156884507 f784efc1518b10dff33673ad9a7a1ac3a7d107d5 blob 51399604 14333430 162328624 $ git rev-list --objects --all | grep f784efc1518b10dff f784efc1518b10dff33673ad9a7a1ac3a7d107d5 toolkits/basemap/data/gshhs_h.txt This shell script is supposed to identify which commits have that blob in their tree (http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob): --- #!/bin/sh obj_name="1ドル" shift git log "$@" --pretty=format:'%T %h %s' \ | while read tree commit subject ; do if git ls-tree -r $tree | grep -q "$obj_name" ; then echo $commit "$subject" fi done --- but it comes up empty, so now I'm stuck. Any ideas would be greatly appreciated.
On Wed, Jan 26, 2011 at 8:38 AM, Darren Dale <dsd...@gm...> wrote: > On Tue, Jan 25, 2011 at 6:12 PM, Darren Dale <dsd...@gm...> wrote: >> There is still an outstanding issue that must be taken care of before >> we migrate. The conversion routines create a basemap repository out of >> trunk/toolkits/basemap, and matplotlib repository out of >> trunk/matplotlib. Still, the matplotlib repo (at >> github.com/darrendale/matplotlib) is over 200 MB. One can search the >> objects in the large packfile, and find that there are still >> references to basemap data in the matplotlib repo. I don't know how it >> got in there, nor how to remove it. > > I went through the exercise of identifying the largest blob, as > described near the end of http://progit.org/book/ch9-7.html : > > $ git verify-pack -v > objects/pack/pack-fa44ca56d7ec3964e562494f2fe08203143074bd.idx | sort > -k 3 -n | tail -3 > 3b8b6c010f8ce59afac1e811b1bbc3efc21b770a blob 9154481 9089827 62749144 > 6328b70e665b58ed7f5aa1e110418cbb3facc07a blob 9331200 94297 156884507 > f784efc1518b10dff33673ad9a7a1ac3a7d107d5 blob 51399604 14333430 162328624 > > $ git rev-list --objects --all | grep f784efc1518b10dff > f784efc1518b10dff33673ad9a7a1ac3a7d107d5 toolkits/basemap/data/gshhs_h.txt > > This shell script is supposed to identify which commits have that blob > in their tree (http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob): > > --- > #!/bin/sh > obj_name="1ドル" > shift > git log "$@" --pretty=format:'%T %h %s' \ > | while read tree commit subject ; do > if git ls-tree -r $tree | grep -q "$obj_name" ; then > echo $commit "$subject" > fi > done > --- > > but it comes up empty, so now I'm stuck. Any ideas would be greatly appreciated. > First of all, I must clarify that I'm not a git expert by any means. I suspected this could be some dangling objects within the repository, which could be side effects of svn2git. After some googling, I found that $ git fsck --unreachable HEAD $(git for-each-ref --format="%(objectname)" refs/heads) This gave me 2774 objects which includes the blob of "toolkits/basemap/data/gshhs_h.txt". Since they are unreachable, I suppose that they can be simply removed. I spend an hour to figure out how we can delete these unreachable objects. But it turned out that the answer seems to be simple. $ git repack -ad Now there is no unreachable object reported and this seems to reduce the total size down to ~140 MB. Now the biggest blob is for "release/osx/matplotlib-0.98.5.tar.gz". and $ git log -r -- release/osx/matplotlib-0.98.5.tar.gz works as expected. And some of the biggest blobs are associated with svg and pdf files. It seems possible to remove these files (if needed) from the repository using "git-filter-branch" to further reduce the size, but I'm not sure if we need that. IHTH, -JJ > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On 01/25/2011 01:38 PM, Darren Dale wrote: > On Tue, Jan 25, 2011 at 6:12 PM, Darren Dale<dsd...@gm...> wrote: >> There is still an outstanding issue that must be taken care of before >> we migrate. The conversion routines create a basemap repository out of >> trunk/toolkits/basemap, and matplotlib repository out of >> trunk/matplotlib. Still, the matplotlib repo (at >> github.com/darrendale/matplotlib) is over 200 MB. One can search the >> objects in the large packfile, and find that there are still >> references to basemap data in the matplotlib repo. I don't know how it >> got in there, nor how to remove it. > Darren, It looks like at least some of the problem is the origin/unit_support: efiring@manini:~/test/matplotlib.git.ddale$ git checkout origin/unit_support Checking out files: 100% (4514/4514), done. Note: checking out 'origin/unit_support'. [...] HEAD is now at 8d705be... refactoring, moved units conversion to units.UnitsManager efiring@manini:~/test/matplotlib.git.ddale$ ls course CVSROOT htdocs matplotlib scipy06 toolkits users_guide It appears to have branched trunk, not trunk/matplotlib. Junk it! I think that losing some bits of history from the git repo is entirely acceptable. The history is still in the svn repo, if anyone really needs to dig back into the earliest recorded origins of unit_support. Eric > I went through the exercise of identifying the largest blob, as > described near the end of http://progit.org/book/ch9-7.html : > > $ git verify-pack -v > objects/pack/pack-fa44ca56d7ec3964e562494f2fe08203143074bd.idx | sort > -k 3 -n | tail -3 > 3b8b6c010f8ce59afac1e811b1bbc3efc21b770a blob 9154481 9089827 62749144 > 6328b70e665b58ed7f5aa1e110418cbb3facc07a blob 9331200 94297 156884507 > f784efc1518b10dff33673ad9a7a1ac3a7d107d5 blob 51399604 14333430 162328624 > > $ git rev-list --objects --all | grep f784efc1518b10dff > f784efc1518b10dff33673ad9a7a1ac3a7d107d5 toolkits/basemap/data/gshhs_h.txt > > This shell script is supposed to identify which commits have that blob > in their tree (http://stackoverflow.com/questions/223678/git-which-commit-has-this-blob): > > --- > #!/bin/sh > obj_name="1ドル" > shift > git log "$@" --pretty=format:'%T %h %s' \ > | while read tree commit subject ; do > if git ls-tree -r $tree | grep -q "$obj_name" ; then > echo $commit "$subject" > fi > done > --- > > but it comes up empty, so now I'm stuck. Any ideas would be greatly appreciated. > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
2011年1月26日 13:37:59 +0900, Jae-Joon Lee wrote: [clip] > I spend an hour to figure out how we can delete these unreachable > objects. But it turned out that the answer seems to be simple. > > $ git repack -ad The complete magic stanza is: git reflog expire --expire=0 --all git prune git repack -f -a -d git gc --prune=0
On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen <pa...@ik...> wrote: > The complete magic stanza is: > > git reflog expire --expire=0 --all > git prune > git repack -f -a -d > git gc --prune=0 Wonderful! With this, I get about 40 MB! Regards, -JJ
On Wed, Jan 26, 2011 at 6:35 AM, Jae-Joon Lee <lee...@gm...> wrote: > On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen <pa...@ik...> wrote: >> The complete magic stanza is: >> >> git reflog expire --expire=0 --all >> git prune >> git repack -f -a -d >> git gc --prune=0 > > Wonderful! > With this, I get about 40 MB! How did you manage to do that? Using these steps (which have been added to the postprocess.sh script): --- run git filter-branch --index-filter \ 'git rm --cached --ignore-unmatch release/osx/matplotlib-0.98.5.tar.gz' \ -- 750059aa09340^.. rm -Rf refs/original rm -Rf logs run git reflog expire --expire=0 --all run git prune run git repack -f -a -d --depth=250 --window=250 run git gc --prune=0 --- I only get down to 65 MB, at which point "git fsck --unreachable HEAD" indicates a slew of unreachable blobs, trees, and commits, one of which is: 3b8b6c010f8ce59afac1e811b1bbc3efc21b770a release/osx/matplotlib-0.98.5.tar.gz yet "git log --pretty=oneline -- release/osx/matplotlib-0.98.5.tar.gz" shows it is no longer associated with any commits. Rerunning the "reflog/prune/repack/gc" block doesn't seem to help at this point.
2011年1月26日 20:35:03 +0900, Jae-Joon Lee wrote: > On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen > <pa...@ik...> wrote: >> The complete magic stanza is: >> >> git reflog expire --expire=0 --all >> git prune >> git repack -f -a -d >> git gc --prune=0 > > Wonderful! > With this, I get about 40 MB! Some additional compression can be obtained by passing also suitable values for the --window and --depth flags for git repack. http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/ Pauli
2011年1月25日 18:12:35 -0500, Darren Dale wrote: [clip] > Pauli: could I trouble you to have a look at my rules file, maybe you > will notice something I overlooked? > (https://github.com/darrendale/mpl2git/blob/master/matplotlib.rules) Any > other ideas? As an additional check, I'd suggest checking that the history graph in each repository is simple. Find all root (parentless) commits: git rev-list --parents master | egrep "^[a-f0-9]{40}$" # for master branch git rev-list --parents --all | egrep "^[a-f0-9]{40}$" # all branches There should be only one root commit, unless there is a very good reason to have several. If there are multiple root commits, this may indicate that the history was splintered into several parts (e.g. due to complicated SVN moves), which needs manual grafting to connect the parts. For perfectionists, I'd also suggest eyeballing the "gitk --all" DAG. -- Pauli Virtanen
On Wed, Jan 26, 2011 at 6:42 AM, Pauli Virtanen <pa...@ik...> wrote: > 2011年1月26日 20:35:03 +0900, Jae-Joon Lee wrote: >> On Wed, Jan 26, 2011 at 7:28 PM, Pauli Virtanen >> <pa...@ik...> wrote: >>> The complete magic stanza is: >>> >>> git reflog expire --expire=0 --all >>> git prune >>> git repack -f -a -d >>> git gc --prune=0 >> >> Wonderful! >> With this, I get about 40 MB! > > Some additional compression can be obtained by passing also suitable > values for the --window and --depth flags for git repack. > > http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/ Thank you all for the helpful feedback. I'll work on this again this evening. Last night I noticed that, in the git repo, the commit messages produced by svnmerge.py still contain a lot of svn-specific information. Pauli's conversion script includes a step that filters out two lines at the end of each commit containing some svn metadata, but for svnmerge commits we still end up with: Merged revisions 8933 via svnmerge from https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint ........ r8933 | weathergod | 2011年01月22日 10:35:26 -0600 (2011年1月22日) | 3 lines Fixing problem where reversed colormaps of LinearSegmentedColormaps were not initialized properly. Thanks to LittleBigBrain for reporting and Friedrich Romstedt for making the original patch. ........ Do we live with this, or try to replace references to svn commits with their git hash and references to svn branches with the git ones? I tried merging the v.1.0.x branch into master, which applied pretty cleanly, with only a few minor merge conflicts: $ git merge origin/v1.0.x Auto-merging CHANGELOG CONFLICT (content): Merge conflict in CHANGELOG Auto-merging examples/api/quad_bezier.py CONFLICT (content): Merge conflict in examples/api/quad_bezier.py Auto-merging lib/matplotlib/__init__.py CONFLICT (content): Merge conflict in lib/matplotlib/__init__.py Auto-merging lib/matplotlib/axes.py Auto-merging lib/matplotlib/backends/backend_macosx.py Auto-merging lib/matplotlib/backends/backend_ps.py Auto-merging lib/matplotlib/backends/backend_qt4.py Auto-merging lib/matplotlib/tests/test_axes.py Auto-merging lib/matplotlib/text.py Auto-merging lib/matplotlib/ticker.py CONFLICT (content): Merge conflict in lib/matplotlib/ticker.py Auto-merging src/_gtkagg.cpp Auto-merging src/_macosx.m CONFLICT (content): Merge conflict in src/_macosx.m Here is the CHANGELOG: <<<<<<< HEAD 2011年01月13日 Added zdir and offset arguments to contourf3d to bring contourf3d in feature parity with contour3d. - BVR 2011年01月04日 Tag 1.0.1 for release at r8896 2011年01月03日 Added display of ticker offset to 3d plots. - BVR 2011年01月03日 Turn off tick labeling on interior subplots for pyplots.subplots when sharex/sharey is True. - JDH 2010年12月29日 Implment axes_divider.HBox and VBox. -JJL ======= 2011年01月04日 Tag 1.0.1 for release at r8896 >>>>>>> origin/v1.0.x
On 01/25/2011 06:53 PM, Eric Firing wrote: [...] > > Darren, > > It looks like at least some of the problem is the origin/unit_support: > > efiring@manini:~/test/matplotlib.git.ddale$ git checkout origin/unit_support > Checking out files: 100% (4514/4514), done. > Note: checking out 'origin/unit_support'. > [...] > HEAD is now at 8d705be... refactoring, moved units conversion to > units.UnitsManager > efiring@manini:~/test/matplotlib.git.ddale$ ls > course CVSROOT htdocs matplotlib scipy06 toolkits users_guide > > It appears to have branched trunk, not trunk/matplotlib. Junk it! > > I think that losing some bits of history from the git repo is entirely > acceptable. The history is still in the svn repo, if anyone really > needs to dig back into the earliest recorded origins of unit_support. > > Eric Or, maybe a rule like this will work? match /branches/unit_support/matplotlib/ repository matplotlib branch unit_support end match (I don't know how significant the parentheses are; I am guessing they are for regular expressions, which are not needed here.) Eric
On Wed, Jan 26, 2011 at 7:44 AM, Darren Dale <dsd...@gm...> wrote: > Last night I noticed that, in the git repo, the commit messages > produced by svnmerge.py still contain a lot of svn-specific > information. Pauli's conversion script includes a step that filters > out two lines at the end of each commit containing some svn metadata, > but for svnmerge commits we still end up with: > > Merged revisions 8933 via svnmerge from > https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint > > ........ > r8933 | weathergod | 2011年01月22日 10:35:26 -0600 (Sat, 22 Jan > 2011) | 3 lines > > Fixing problem where reversed colormaps of > LinearSegmentedColormaps were not initialized properly. > Thanks to LittleBigBrain for reporting and Friedrich Romstedt > for making the original patch. > ........ > > Do we live with this, or try to replace references to svn commits with > their git hash and references to svn branches with the git ones? I think I just convinced myself that replacing svn references with git hashes would be a Herculean task. One could generate a svn_rev:git_hash mapping, but then changing the commit message actually yields a new git hash, breaking the mapping. Its not an impossible task, but it would be a lot of work and difficult to check. Leaving the svn path and revision information will probably be more reliable. "git log --all" will therefore yield enough information that we can easily identify the provenance of a cherry pick and find it in the git history: commit adb1a7f67daf955a1af3a86d42b5181767c18819 Author: Ben Root <ben...@gm...> Date: Sat Jan 22 16:40:21 2011 +0000 Merged revisions 8933 via svnmerge from https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_main ........ r8933 | weathergod | 2011年01月22日 10:35:26 -0600 (2011年1月22日) | 3 line Fixing problem where reversed colormaps of LinearSegmentedColormaps were n Thanks to LittleBigBrain for reporting and Friedrich Romstedt for making t ........ svn path=/trunk/matplotlib/; revision=8934 commit 2fa57c710607496a93000bfb3191bdd422f518cc Author: Ben Root <ben...@gm...> Date: Sat Jan 22 16:35:26 2011 +0000 Fixing problem where reversed colormaps of LinearSegmentedColormaps were not Thanks to LittleBigBrain for reporting and Friedrich Romstedt for making the svn path=/branches/v1_0_maint/; revision=8933 Is this satisfactory? Darren
On Wednesday, January 26, 2011, Darren Dale <dsd...@gm...> wrote: > On Wed, Jan 26, 2011 at 7:44 AM, Darren Dale <dsd...@gm...> wrote: >> Last night I noticed that, in the git repo, the commit messages >> produced by svnmerge.py still contain a lot of svn-specific >> information. Pauli's conversion script includes a step that filters >> out two lines at the end of each commit containing some svn metadata, >> but for svnmerge commits we still end up with: >> >> Merged revisions 8933 via svnmerge from >> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_maint >> >> ........ >> r8933 | weathergod | 2011年01月22日 10:35:26 -0600 (Sat, 22 Jan >> 2011) | 3 lines >> >> Fixing problem where reversed colormaps of >> LinearSegmentedColormaps were not initialized properly. >> Thanks to LittleBigBrain for reporting and Friedrich Romstedt >> for making the original patch. >> ........ >> >> Do we live with this, or try to replace references to svn commits with >> their git hash and references to svn branches with the git ones? > > I think I just convinced myself that replacing svn references with git > hashes would be a Herculean task. One could generate a > svn_rev:git_hash mapping, but then changing the commit message > actually yields a new git hash, breaking the mapping. Its not an > impossible task, but it would be a lot of work and difficult to check. > Leaving the svn path and revision information will probably be more > reliable. "git log --all" will therefore yield enough information that > we can easily identify the provenance of a cherry pick and find it in > the git history: > > commit adb1a7f67daf955a1af3a86d42b5181767c18819 > Author: Ben Root <ben...@gm...> > Date: Sat Jan 22 16:40:21 2011 +0000 > > Merged revisions 8933 via svnmerge from > https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v1_0_main > > ........ > r8933 | weathergod | 2011年01月22日 10:35:26 -0600 (2011年1月22日) | 3 line > > Fixing problem where reversed colormaps of LinearSegmentedColormaps were n > Thanks to LittleBigBrain for reporting and Friedrich Romstedt for making t > ........ > > svn path=/trunk/matplotlib/; revision=8934 > > commit 2fa57c710607496a93000bfb3191bdd422f518cc > Author: Ben Root <ben...@gm...> > Date: Sat Jan 22 16:35:26 2011 +0000 > > Fixing problem where reversed colormaps of LinearSegmentedColormaps were not > Thanks to LittleBigBrain for reporting and Friedrich Romstedt for making the > > svn path=/branches/v1_0_maint/; revision=8933 > > > Is this satisfactory? > > Darren > I think it is fine. Maybe a nice convenience script would be one that would return a got hash for a svn revision number (and vice verse?). With that, I would be more than happy with how the logs are. Ben Root
On Tue, Jan 25, 2011 at 11:37 PM, Jae-Joon Lee <lee...@gm...> wrote: > And some of the biggest blobs are associated with svg and pdf files. > It seems possible to remove these files (if needed) from the > repository using "git-filter-branch" to further reduce the size, but > I'm not sure if we need that. Some of this appears to be the result of some svn tags referencing the contents of trunk/htdocs. It looks like I can cut 25 MB off the size of the repo.
On Thu, Jan 27, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote: > On Tue, Jan 25, 2011 at 11:37 PM, Jae-Joon Lee <lee...@gm...> wrote: >> And some of the biggest blobs are associated with svg and pdf files. >> It seems possible to remove these files (if needed) from the >> repository using "git-filter-branch" to further reduce the size, but >> I'm not sure if we need that. > > Some of this appears to be the result of some svn tags referencing the > contents of trunk/htdocs. It looks like I can cut 25 MB off the size > of the repo. That feels pretty good to me, considering that the compressed release tarball is 13MB. If we can get the whole history for twice that, then you must be getting pretty close to the limit. JDH
On Thu, Jan 27, 2011 at 12:00 PM, John Hunter <jd...@gm...> wrote: > On Thu, Jan 27, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote: >> On Tue, Jan 25, 2011 at 11:37 PM, Jae-Joon Lee <lee...@gm...> wrote: >>> And some of the biggest blobs are associated with svg and pdf files. >>> It seems possible to remove these files (if needed) from the >>> repository using "git-filter-branch" to further reduce the size, but >>> I'm not sure if we need that. >> >> Some of this appears to be the result of some svn tags referencing the >> contents of trunk/htdocs. It looks like I can cut 25 MB off the size >> of the repo. > > That feels pretty good to me, considering that the compressed release > tarball is 13MB. If we can get the whole history for twice that, then > you must be getting pretty close to the limit. Me too. I just posted the latest version of the repository to github.com/darrendale/matplotlib.git . Its ~42MB, but it has a bunch of unreachable objects. As soon as we figure out how to git rid of them, I think we will be ready to freeze the svn repo and wrap this up.
2011年1月27日 12:39:48 -0500, Darren Dale wrote: [clip] > Me too. I just posted the latest version of the repository to > github.com/darrendale/matplotlib.git . Its ~42MB, but it has a bunch of > unreachable objects. As soon as we figure out how to git rid of them, I > think we will be ready to freeze the svn repo and wrap this up. Unreachable from where? How do you know there are unreachable objects? Note that the snippet git fsck --unreachable HEAD $(git for-each-ref --format="%(objectname)" refs/heads) only checks for objects unreachable from branches (by definition, stuff under refs/heads). However, there's also other stuff under refs/: tags and hidden branches. Especially the postprocess.sh script hides some branches. To see all that is there, check the output from git for-each-ref -- Pauli Virtanen