On 11-02-13 06:15 PM, Brion Vibber wrote: > On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De Dauw<[email protected]>wrote: > >>> +1 to migrate to a DVCS >> Unless I'm mistaken no one has actually suggested doing that. >> > That's been talked about a few times here already. :) > > There's some notes about potential git migration plans of action at: > http://www.mediawiki.org/wiki/Git_conversion > > I know Avar's looked into it to various degrees, there may be some more > notes sitting about. I'm definitely in favor of it getting done in some way, > though there remain basic issues of what to do with extensions -- roll > everything into a giant repo with core and all extensions, or do extensions > separate but make it harder to maintain a full consistent versioned set? > > I can definitely say that working with branching and merging in git is > FANTASTIC -- especially for the ability to use source control as your > workspace for in-progress patches, so you get the full benefits of > versioning *and* sharing while still working on something. > > -- brion Don't forget about what git does for those of us using remote servers too. The ease of development between working on my monaco-port (in git for now) vs. making core changes (svn of course) is fairly noticeable.
I do my development and testing on remote servers, and multiple ones at that (monaco-port is actually located in 4 or 5 locations; My local repo, on the dragonballencyclopedia's prototype and live site, another location still setup on commonjs (I used to use it for experimenting before I had other wikis to try it on) and in my trunktest for development in a 1.18 env). And I usually vary whether I work on a feature from the dragonballencyclopedia prototype or trunktest. Sometimes doing a little work on both since one is a 1.16 env and the other trunk and some features vary in support over that border. The last key piece of background, is I don't commit/push things to remote repos from these servers. I don't trust my own servers with any of my private keys used to commit to remote repos (sure, I have separate keys, and I could give it just the ability to push to the repo without accessing other servers... but I don't trust my own servers enough to give them the ability to commit something to Wikimedia's svn under my name). Hence any task of committing/pushing to a remote repo is done from my physical computer, not the server, despite 99% of the actual development being on the servers. So since I work on remote machines, but commit from my local machine I need to find a way to transfer the changes from the remote machine to the local machine before submitting them. This is completely trivial with git. I just make the actual commit on the server itself (since I don't need any special access for that). Then I pull from my machine to pull those changes from the server into my local copy. And finally I push those changes to the public repo. Only takes a few seconds. I even have a trivial shell script for monaco-port that pulls changes from all my remote repos into my local one, pushes that to my github repo, and then makes sure each of my servers using monaco-port are up to date. (It's really just a series of git pull/push commands) But when it comes to svn... I've taken to the habit of running `ssh <server> "cd /path/to/wiki; svn diff" | patch -p0`. Naturally I have to svn up both copies before that to avoid any mishaps. And if I added a new file, I have to do a separate explicit scp. And after that I have to go back to the remote server, and svn up it again so that it understands that those changes are no longer a dirty working copy. If I added a file sometimes I have to deal with a slight mess. And if I forget to svn up, have to deal with some blech from patch. etc... Naturally of course, git is also beautiful for my disorganized working copy. Right now trunktest has some uncommitted stuff I'm experimenting with. And I usually end up transferring my changes to my local copy, then reverting everything not relevant, and in the off case where two experiments used the same file, I have to manually edit one of those out (though I slightly streamlined that by piping svn diff <file> to a file, running svn revert <file>, editing the patch and deleting the change I don't want to commit, and then running the patch command; rather than manually undoing the code). Git changes that extremely, since there is an index I just explicitly say which parts I want to add to the index to commit. And it works beautifully for files where two experiments work on the same file, I can look through the file and explicitly say which diff chunks I actually DO want to commit without having to edit the file. And `git gui` really does make picking those diff chunks easier (yay for ssh -X too). ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
