On 16 September 2014 20:53, Andrew Stitcher <[email protected]> wrote:
> On Tue, 2014-09-16 at 17:35 +0100, Robbie Gemmell wrote: > > Hello all, > > > > I mentioned this briefly in a previous thread, and have decided just to > > call a vote on the subject. I would like to migrate the repo for the new > > JMS client work to use Git rather than Subversion. > > > > This wont affect the rest of the Qpid codebase, though it could be viewed > > as a test for any such move in future. Only the bits in the following > > subtree are under consideration for migation at this time: > > http://svn.apache.org/repos/asf/qpid/jms/ > > > > I believe it would make things easier for those of us currently working > on > > it, and ease future usage of things like the Github integration we > > can/should have Apache infra enable. For anyone still wanting to use a > > Subversion client to check things out, there will still be an option > there > > as e.g. Github repos can also be checked out with svn clients, and Apache > > mirror things to Github. > > Before voting, I'd like more information: > * Can you say in more detail what this migration entails? > Essentially, stop commits to the old repo, do the copy, allow commits to the new repo. Commit emails to the mailing list would still be available, but change format a little to account for the differing info of each commit. The updates posted on JIRAs would also still be available. The web interface would transition from viewvc to git-web, e.g: https://git-wip-us.apache.org/repos/asf?p=hadoop.git;a=summary According to an infra post a similar JIRA requests from another project, the core switchover process is roughly: " I will begin the transition towards Git on Sunday, as that is the least busy day for commits in general. The following steps will take place: 1) The Subversion repository will be made read-only. 2) The Git repository will be set up and also be read-only. 3) You will verify that the contents of the Git repository matches the Subversion contents. 4) Once acked, I will make the Git repo writeable and that should be it." I believe the old repo contents are typically left in place, though given the lack of widespread use or releases for this code it might not be unreasonable to enquire about possibility of its complete removal to avoid clutter. > * What is the advantage of making git primary over using git-svn as many > of us already do, to reasonable effect. > For me it would mainly be lots of little things adding up, including but not necessarily limited to: - Moving files retaining their history for inspection via gitk etc (I happened to move all of the files in question just the other day, and thus cant see any of their commit history via gitk anymore, annoying). - Merge history tracking without having to fall back to using svn itself to do the merges, which is painfully slow and almost nobody else here using git-svn actually seems to bother doing, or screwing around with the svn:mergeinfo properties manually. - Merging etc between remote branches and multiple git repos without worrying about git-svn-id entries in the logs potentially messing things up. - Not having to clean up the empty directories left behind by all us git-svn users. - Not having the svn:ignore props be out of date because people only update the .gitignore files. I get the impression the Github integration, which I'd like us to use, works a bit better with the Git repos as well. I'd certainly like to have a more git-friendly workflow in place, which a number of other projects do these days. I'll admit that part of it is also just that I have been using git-svn for perhaps 6 years now and would like to finally make the full conversion, as many prominent projects at Apache have. The last time this idea was floated (for the whole Qpid repo, not just the small part I'm suggesting now) I believe I said I'd like other projects to prove out the process first, and I think they now have. Robbie
