Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Tue, Sep 14, 2010 at 04:51:39PM -0700, Fernando Perez wrote: I've heard several people say that once they used git, they can't imagine going back to SVN. As you were writing this, Min RK and I were discussing on IRC: minrk1 there are so many people who provide patches on github, since the process is so easy fperez I couldn't think of going back from git to svn now. While I find that git has its limitations (I have never made more user mistakes with data-loss consequences using git than with another VCS), github is just really awesome and way ahead of everything else, I believe. In terms of workflow in an open source project with many contributors, core and non-core, its a great gain. Gael ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On 09/15/2010 04:21 PM, Gael Varoquaux wrote: On Tue, Sep 14, 2010 at 04:51:39PM -0700, Fernando Perez wrote: I've heard several people say that once they used git, they can't imagine going back to SVN. As you were writing this, Min RK and I were discussing on IRC: minrk1 there are so many people who provide patches on github, since the process is so easy fperez I couldn't think of going back from git to svn now. While I find that git has its limitations (I have never made more user mistakes with data-loss consequences using git than with another VCS) It is very difficult to actually lose data with git thanks to the reflog: http://www.gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 05:10:53PM +0900, David wrote: It is very difficult to actually lose data with git thanks to the reflog: http://www.gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html Unless you use the 'force' switches. I am trying very hard not to use them, as I have been advised by several good git users. But I keep getting in situations where people tell me that I need to use one of these switches. It's always a bit hard to explain how I get there, but I'll try and do so, so that knowledgeable people can advice me on the right solutions. Here is an example (in chronological order): 1) Branch out a feature branch 'feature' from master. 2) Develop in feature branch (cycle of code/commit...) 3) Hot bug on master, checkout master, attempt to fix bug. Bug fix induces other bugs, cycle of code/commit to fix them. 4) Decide that bug fix is not mature enough to push, but feature branch got reviewed and is. 5) Discover that I can't push from feature to origin/master. Conclude that I must merge back in master locally. Now I have a problem: at step 1 I should have created a branch. I did not. I need to go back and create a branch. This was happening at a sprint, and people that know git better than me helped me out. But the only way we found to sort this out was to create a branch at step 1, merge the branch with master, and 'reset -a' master at step 1. I thought it over quite a few times, and did not loose any data. However, I was very uncomfortable with the process (the 'reset -a'). What was the right solution (apart from 'create branch at step 1')? This really illustrates what git feels like me: linux in root mode, powerful, unsafe if you don't understand it well. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On 09/15/2010 05:58 PM, Gael Varoquaux wrote: On Wed, Sep 15, 2010 at 05:10:53PM +0900, David wrote: It is very difficult to actually lose data with git thanks to the reflog: http://www.gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html Unless you use the 'force' switches. I am trying very hard not to use them, as I have been advised by several good git users. Well, yes and no. For example, you can not loose commits with any command that I know of thanks to the reflog (and this is true even if you use really hard commands like git reset --hard somecommit). But I keep getting in situations where people tell me that I need to use one of these switches. It's always a bit hard to explain how I get there, but I'll try and do so, so that knowledgeable people can advice me on the right solutions. Here is an example (in chronological order): 1) Branch out a feature branch 'feature' from master. 2) Develop in feature branch (cycle of code/commit...) 3) Hot bug on master, checkout master, attempt to fix bug. Bug fix induces other bugs, cycle of code/commit to fix them. 4) Decide that bug fix is not mature enough to push, but feature branch got reviewed and is. 5) Discover that I can't push from feature to origin/master. Conclude that I must merge back in master locally. Now I have a problem: at step 1 I should have created a branch. I did not. I need to go back and create a branch. This was happening at a sprint, and people that know git better than me helped me out. But the only way we found to sort this out was to create a branch at step 1, merge the branch with master, and 'reset -a' master at step 1. I thought it over quite a few times, and did not loose any data. However, I was very uncomfortable with the process (the 'reset -a'). I am not sure I understand your issue exactly. Do you mean you put some commits in the wrong branch ? I don't see how reset is related to that - I mean, I have used git for two years, and I don't even know what reset -a does, much less used it :) cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 06:55:46PM +0900, David wrote: Unless you use the 'force' switches. I am trying very hard not to use them, as I have been advised by several good git users. Well, yes and no. For example, you can not loose commits with any command that I know of thanks to the reflog (and this is true even if you use really hard commands like git reset --hard somecommit). Cool, very handy. I wasn't aware of this. Is there a GUI for reflog (in any one of the many GUIs, I don't really care)? I don't use reflog much because I don't understand it, and don't really know what operations I can do on it (still learning). Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 10:08:21AM +, Pauli Virtanen wrote: Pushing to origin/master from feature should be possible: $ git checkout feature $ git fetch origin $ git merge origin/master # if needed $ git push origin feature:master That's what I was missing! Thanks, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 8:48 PM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
On Wed, Sep 15, 2010 at 06:55:46PM +0900, David wrote:
Unless you use the 'force' switches. I am trying very hard not to
use them, as I have been advised by several good git users.
Well, yes and no. For example, you can not loose commits with any
command that I know of thanks to the reflog (and this is true even if
you use really hard commands like git reset --hard somecommit).
Cool, very handy. I wasn't aware of this. Is there a GUI for reflog (in
any one of the many GUIs, I don't really care)? I don't use reflog much
because I don't understand it, and don't really know what operations I
can do on it (still learning).
The basic way to use reflog is trivial: it just keeps a (time ordered)
list of your commits and actions, independently of the branch. So for
example, say you are in master, and by accident, you do:
git reset --hard origin/master # origin/master is behind master
git reflog
will look like:
b59aa8c h...@{0}: origin/master: updating HEAD
ad5c0c0 h...@{1}: pull github master: Fast forward
d11b913 h...@{2}: commit: ENH: add builder override support for
compiled libraries.
2423a03 h...@{3}: commit: FEAT: add get_compiled_libraries to get all
clib from all subpackages.
ae4c57b h...@{4}: merge tmp: Fast forward
f4c4b53 h...@{5}: github/master: updating HEAD
ae4c57b h...@{6}: checkout: moving from tmp to master
ae4c57b h...@{7}: checkout: moving from
ae4c57bab5583759aab831eafce0c9b83a5f9c45 to tmp
...
So you know exactly how to go back any point in time - that is until
the reflog is purged (which is something like 30 days by default I
think).
The key point is that any operation you do in git w.r.t. commits is
moving in the graph, so resetting, checking out, etc... do not lose
anything. In particular, reset --hard only get you back to some node
of that graph, without removing the old one. That's also useful when
you need to revert some merge, etc... Although, as mentioned by pv, it
does not preclude doing potentially harming operations in separate
branches (if only because it is simpler).
cheers,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 09:54:24PM +0900, David Cournapeau wrote:
The basic way to use reflog is trivial: it just keeps a (time ordered)
list of your commits and actions, independently of the branch. So for
example, say you are in master, and by accident, you do:
git reset --hard origin/master # origin/master is behind master
git reflog
will look like:
b59aa8c h...@{0}: origin/master: updating HEAD
ad5c0c0 h...@{1}: pull github master: Fast forward
d11b913 h...@{2}: commit: ENH: add builder override support for
compiled libraries.
2423a03 h...@{3}: commit: FEAT: add get_compiled_libraries to get all
clib from all subpackages.
ae4c57b h...@{4}: merge tmp: Fast forward
f4c4b53 h...@{5}: github/master: updating HEAD
ae4c57b h...@{6}: checkout: moving from tmp to master
ae4c57b h...@{7}: checkout: moving from
ae4c57bab5583759aab831eafce0c9b83a5f9c45 to tmp
...
I don't understand which line corresponds to the 'reset --hard' in the
above reflog (sorry, I am slow). Is it the 'updating HEAD' one?
Reading the above, it seemed to me that I could always revert my previous
action (unless it impacted non-tracked files) using:
git checkout h...@{0}
I just tried it on a copy of a repo I had, and I get You are in a
'detached HEAD'. From what I understand from the message (and Google) I
simply need to do a git checkout -b new_branch to be in a state where I
can work. However, it seem to me that when I switch back the the master
branch, and merge my new_branch, I haven't undone the action I was
trying to undo.
Sorry for asking these questions, but I'd rather be dense and ask them
while I am playing with a toy repo than suffer from my git inability
later on a real situation, which usually happens at 2AM.
Thanks for you git-foo
Gaël
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 8:09 AM, Gael Varoquaux
gael.varoqu...@normalesup.org wrote:
On Wed, Sep 15, 2010 at 09:54:24PM +0900, David Cournapeau wrote:
The basic way to use reflog is trivial: it just keeps a (time ordered)
list of your commits and actions, independently of the branch. So for
example, say you are in master, and by accident, you do:
git reset --hard origin/master # origin/master is behind master
git reflog
will look like:
b59aa8c h...@{0}: origin/master: updating HEAD
ad5c0c0 h...@{1}: pull github master: Fast forward
d11b913 h...@{2}: commit: ENH: add builder override support for
compiled libraries.
2423a03 h...@{3}: commit: FEAT: add get_compiled_libraries to get all
clib from all subpackages.
ae4c57b h...@{4}: merge tmp: Fast forward
f4c4b53 h...@{5}: github/master: updating HEAD
ae4c57b h...@{6}: checkout: moving from tmp to master
ae4c57b h...@{7}: checkout: moving from
ae4c57bab5583759aab831eafce0c9b83a5f9c45 to tmp
...
I don't understand which line corresponds to the 'reset --hard' in the
above reflog (sorry, I am slow). Is it the 'updating HEAD' one?
Reading the above, it seemed to me that I could always revert my previous
action (unless it impacted non-tracked files) using:
git checkout h...@{0}
I just tried it on a copy of a repo I had, and I get You are in a
'detached HEAD'. From what I understand from the message (and Google) I
simply need to do a git checkout -b new_branch to be in a state where I
can work. However, it seem to me that when I switch back the the master
branch, and merge my new_branch, I haven't undone the action I was
trying to undo.
Sorry for asking these questions, but I'd rather be dense and ask them
while I am playing with a toy repo than suffer from my git inability
later on a real situation, which usually happens at 2AM.
Thanks for you git-foo
Gaël
I have to ditto the earlier sentiment about how easy it is to mess up in git
(as compared to svn). I read the git parable and (I thought) I understood
the elegance of how git works, only to later discover that there was still
plenty of details that I just didn't get. It is probably a good thing
that we are cutting our teeth on toy repositories first.
Anyway, I would just like to voice two of the most important things I have
learned about git. First, 'git revert' != 'svn revert' (seriously, Linus...
why?).
Second, 'git stash' is your friend. If you haven't come across stash yet,
here is a quick use-case. Imagine you are working on adding a particular
feature and have made some changes. Along the way, you discover an
unrelated bug. You can 'stash' the changes you made so far, reverting back
to the state at the last commit, and then fix that bug. You then commit
*that* bugfix (to the proper branch, of course), then you can 'pop' the
stashed changes and be back to where you were when you did the stash (with
the bugfix). Lovely feature... :)
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 03:07:52PM +, Pauli Virtanen wrote:
and pick a state that seems good, usually somebra...@{1} if you didn't do
new commits etc. on the branch yet:
$ git checkout somebra...@{1}
... check now that this is the state you'd like somebranch to have...
$ git branch -f somebranch somebra...@{1}
OK, the above was what I was missing. Thanks a lot, it's very useful.
Note that
$ git reflog
does *NOT* show the reflog of the current branch -- it shows the reflog
of HEAD, which can in some cases be confusing. The point is that HEAD is
a meta-branch that corresponds to the current checkout, and so changes
every time you use git checkout.
Thank you, I hadn't realized!
Gaël
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
snip Now that we have the repository, let's revisit the .gitignore file that I removed from svn. IIRC, Stefan complained and Pauli more or less agreed with the removal. However, after browsing about the net, the suggested policy is that files that should be excluded in all the clones of the repository should go in .gitignore and local exclusions should go in .git/info/exclude. So it seems we should commit a .gitignore file just to help avoid accidental additions. As a start, I suggest the following contents: *.o *.a *.pyc *.swp *~ build Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 11:10, Charles R Harris charlesr.har...@gmail.com wrote: snip Now that we have the repository, let's revisit the .gitignore file that I removed from svn. IIRC, Stefan complained and Pauli more or less agreed with the removal. However, after browsing about the net, the suggested policy is that files that should be excluded in all the clones of the repository should go in .gitignore and local exclusions should go in .git/info/exclude. So it seems we should commit a .gitignore file just to help avoid accidental additions. As a start, I suggest the following contents: *.o *.a *.pyc *.swp *~ build *.pyo *.so *.pyd .gdb_history dist -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Wed, 15 Sep 2010 11:16:35 -0500, Robert Kern wrote: [clip: .gitignore] *.o *.a *.pyc *.swp *~ build *.pyo *.so *.pyd .gdb_history dist /build /dist /doc/build /doc/cdoc/build .\#* *.log *.egg-info /numpy/core/__svn_version__.py /doc/numpy.scipy.org/_build The .\#* is for emacs. But let's do this directly in Git, so that I don't have to bother regenerating the Numpy repo. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 10:27 AM, Pauli Virtanen p...@iki.fi wrote: Wed, 15 Sep 2010 11:16:35 -0500, Robert Kern wrote: [clip: .gitignore] *.o *.a *.pyc *.swp *~ build *.pyo *.so *.pyd .gdb_history dist /build /dist /doc/build /doc/cdoc/build .\#* *.log *.egg-info /numpy/core/__svn_version__.py /doc/numpy.scipy.org/_build The .\#* is for emacs. But let's do this directly in Git, so that I don't have to bother regenerating the Numpy repo. OK, there is a version at http://github.com/charris/numpy/tree/misc Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Wed, Sep 15, 2010 at 1:05 AM, Travis Oliphant oliph...@enthought.com wrote: Thanks! This is really great work. So much thanks is due to Pauli and David for making this happen. I will get Aaron River to freeze the SVN trunk as well as work on trac integration. With the last re-install of Trac we integrated a Git browser (optimistic anticipation!): http://projects.scipy.org/numpy/browse_git But I think we can simply replace this with a link to GitHub now? Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Sep 13, 2010, at 3:46 PM, Charles R Harris wrote: On Mon, Sep 13, 2010 at 2:33 PM, Travis Oliphant oliph...@enthought.com wrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I didn't see any problems, but I didn't use the test repository that much. Maybe we should just make the jump and iron out any little wrinkles as they show up. Losing small bits of history doesn't bother me much. I think you guys have a big chore ahead of you to merge the refactored stuff while keeping all the fixes that have gone in since the fork. Good Luck! I know. That's why I want to do it with git as much as possible... ;-) -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Sep 13, 2010, at 6:20 PM, Pauli Virtanen wrote: Mon, 13 Sep 2010 21:41:18 +, Pauli Virtanen wrote: [clip] I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). Here we go: http://github.com/numpy/numpy http://github.com/numpy/vendor Thanks! This is really great work. So much thanks is due to Pauli and David for making this happen. I will get Aaron River to freeze the SVN trunk as well as work on trac integration. There may be some learning for using the git workflow, and but it sounds like there are some good tutorials for doing it. I've heard several people say that once they used git, they can't imagine going back to SVN. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Tue, Sep 14, 2010 at 4:05 PM, Travis Oliphant oliph...@enthought.com wrote: Here we go: http://github.com/numpy/numpy http://github.com/numpy/vendor Thanks! This is really great work. So much thanks is due to Pauli and David for making this happen. I will get Aaron River to freeze the SVN trunk as well as work on trac integration. Ditto thanks! There may be some learning for using the git workflow, and but it sounds like there are some good tutorials for doing it. I keep a list of resources here in case someone finds them useful: http://fperez.org/py4science/git.html I've heard several people say that once they used git, they can't imagine going back to SVN. As you were writing this, Min RK and I were discussing on IRC: minrk1 there are so many people who provide patches on github, since the process is so easy fperez I couldn't think of going back from git to svn now. :) Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Mon, Sep 13, 2010 at 2:33 PM, Travis Oliphant oliph...@enthought.comwrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I didn't see any problems, but I didn't use the test repository that much. Maybe we should just make the jump and iron out any little wrinkles as they show up. Losing small bits of history doesn't bother me much. I think you guys have a big chore ahead of you to merge the refactored stuff while keeping all the fixes that have gone in since the fork. Good Luck! Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Mon, 13 Sep 2010 15:33:11 -0500, Travis Oliphant wrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? As far as the conversion is concerned, things should be OK. The bugs in svn-all-fast-export have been fixed in the meantime, and we have scripts for comparing checksums for each revision. It's hardly possible to lose anything. Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Mon, 13 Sep 2010 21:41:18 +, Pauli Virtanen wrote: [clip] I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). Here we go: http://github.com/numpy/numpy http://github.com/numpy/vendor ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Hi Pauli, On Mon, Sep 13, 2010 at 5:20 PM, Pauli Virtanen p...@iki.fi wrote: Mon, 13 Sep 2010 21:41:18 +, Pauli Virtanen wrote: [clip] I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). Here we go: http://github.com/numpy/numpy http://github.com/numpy/vendor What is the suggested work flow for the new repositories? Is the best way to use a github fork and push and pull from that? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Mon, Sep 13, 2010 at 3:41 PM, Pauli Virtanen p...@iki.fi wrote: Mon, 13 Sep 2010 15:33:11 -0500, Travis Oliphant wrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? As far as the conversion is concerned, things should be OK. The bugs in svn-all-fast-export have been fixed in the meantime, and we have scripts for comparing checksums for each revision. It's hardly possible to lose anything. Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). I think we should freeze the svn repo as soon as possible. Pierre is still making commits there and unless there is an easy way to update the git repo from svn those sort of commits might be a small hassle. So, I suggest a short post to the list announcing a svn freeze. How does trac integrate with the new repo? Will the mailing lists still work? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Mon, 13 Sep 2010 18:08:39 -0600, Charles R Harris wrote: [clip] What is the suggested work flow for the new repositories? Is the best way to use a github fork and push and pull from that? Yes, I'd personally work like that. Easier to keep private stuff separate. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Howdy, On Mon, Sep 13, 2010 at 5:24 PM, Pauli Virtanen p...@iki.fi wrote: What is the suggested work flow for the new repositories? Is the best way to use a github fork and push and pull from that? Yes, I'd personally work like that. Easier to keep private stuff separate. in case you find it useful, Matthew Brett wrote up a summary of the 'typical' git workflow in a way that should be easy to include in a project's doc tree and rebuild it with URLs specific to that project, for easy copy/paste. It's his gitwash git repo: http://github.com/matthew-brett/gitwash here's an example of gitwash 'rendered' for the IPython urls: http://ipython.scipy.org/doc/nightly/html/development/gitwash/index.html It's a good start of a fairly common workflow pattern, and if various projects find it useful and submit their fixes upstream, this pattern will become more familiar and easier to follow reliably by end users/developers. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
Mon, 13 Sep 2010 18:15:01 -0600, Charles R Harris wrote: [clip] I think we should freeze the svn repo as soon as possible. Pierre is still making commits there and unless there is an easy way to update the git repo from svn those sort of commits might be a small hassle. It needs re-generation of the whole repo which is a bit slow, but it's reproducible and ends up with the same hashes, so in principle we can update later on. So, I suggest a short post to the list announcing a svn freeze. How does trac integrate with the new repo? It doesn't at the moment. There are some plugins, though: http://github.com/davglass/github-trac/ http://trac-hacks.org/wiki/GitPlugin/ However, I'm not sure if we really need anything else than a way to link to commits in bug reports (which can be done by pasting URLs anyway). I'd prefer to keep maintenance overhead low, and just use Github's source browser and timeline utilities. Will the mailing lists still work? Yes, Github can AFAIK be configured to send emails to a given address. However, I guess the Numpy list must be configured to accept mails from Github. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Mon, Sep 13, 2010 at 7:15 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 13, 2010 at 3:41 PM, Pauli Virtanen p...@iki.fi wrote: Mon, 13 Sep 2010 15:33:11 -0500, Travis Oliphant wrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? As far as the conversion is concerned, things should be OK. The bugs in svn-all-fast-export have been fixed in the meantime, and we have scripts for comparing checksums for each revision. It's hardly possible to lose anything. Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). I think we should freeze the svn repo as soon as possible. Pierre is still making commits there and unless there is an easy way to update the git repo from svn those sort of commits might be a small hassle. So, I suggest a short post to the list announcing a svn freeze. How does trac integrate with the new repo? Will the mailing lists still work? Chuck Can you also update the web site (front page and Developer Zone http://www.scipy.org/Developer_Zone ) with the new information? At least highlight that the git is now being used as presumably the svn version will no longer be maintained. It would also be nice for this information to included as a main point in the forthcoming release. Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Can we freeze the subversion repository and move to github this week?
On Mon, Sep 13, 2010 at 8:10 PM, Bruce Southey bsout...@gmail.com wrote: On Mon, Sep 13, 2010 at 7:15 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Sep 13, 2010 at 3:41 PM, Pauli Virtanen p...@iki.fi wrote: Mon, 13 Sep 2010 15:33:11 -0500, Travis Oliphant wrote: Are we ready to do this yet? I know there were some outstanding questions. Are there major concerns remaining? As far as the conversion is concerned, things should be OK. The bugs in svn-all-fast-export have been fixed in the meantime, and we have scripts for comparing checksums for each revision. It's hardly possible to lose anything. Or, is it just picking a time to freeze subversion when someone like David or Pauli who know how to move the repository to github correctly a time to do it. I can upload a final repository today/tomorrow. If it seems OK, we can freeze SVN trunk a few days after that. Or we can freeze the trunk sooner than that after the final repo is up, and patch up things manually, if something turns up (unlikely). I think we should freeze the svn repo as soon as possible. Pierre is still making commits there and unless there is an easy way to update the git repo from svn those sort of commits might be a small hassle. So, I suggest a short post to the list announcing a svn freeze. How does trac integrate with the new repo? Will the mailing lists still work? Chuck Can you also update the web site (front page and Developer Zone http://www.scipy.org/Developer_Zone ) with the new information? At least highlight that the git is now being used as presumably the svn version will no longer be maintained. It would also be nice for this information to included as a main point in the forthcoming release. Bruce Might also want to fix the README.txt file... The most current development version is always available from our subversion repository: http://svn.scipy.org/svn/numpy/trunk Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
