On 11-02-13 06:15 PM, Brion Vibber wrote:
On Sun, Feb 13, 2011 at 5:49 PM, Jeroen De
Dauw<jeroendedauw(a)gmail.com>wrote;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]