I'd say that I found Git slightly more complicated when it comes to
mimicking svn functionality, but significantly more complicated when
trying
to do more complex operations. Of course, this is because Git allows you
to do more, but it definitely should be noted that there will be learning
curve, and that should be taken into account when deciding if/when we want
to migrate the core code... even after I thought I understood conceptually
how I was supposed to be using Git, I ran into some trouble.
One thing I wanted to do for the sprint was try the model Burke mentioned
in a recent email where all developers wouldn't need to have push
privilege
to the master repo... but rather would make pull requests of the master
repo. The sprint seemed like a great time to test this functionality out.
But when I spent some time the weekend before the sprint trying to write
up instructions on how to do this, I wasn't able to figure out the correct
workflow exactly... I WAS able to create my own remote fork of the
htmlformentry master branch, check that out, make changes, push the
changes
back up to Git, and then make a pull request to the htmlformentry master
from my remote fork... but what I WASN'T able to do was to figure the
right
workflow for merging in any changes from the master repo before making my
pull request. So I decided to pass on trying to having people do it that
way and just gave people push access to the main repo because I didn't
want
to spend a lot of of the sprint working out Git issues with understandably
frustrated developers and/or having to resolve a lot of merge issues
myself. I'm sure this IS possible, but my point is we shouldn't assume
that it is trivia to learn how to do... and if we do have a university
call, it would probably be best led by someone other than me who can
actually explain how to do it... :)
Also, I will note that when I did run into conflicts, conflict resolution
seemed pretty similar to conflict resolution with svn... i.e., I didn't
notice any great improvement.
And finally, the Egit plugin, while not horrible, did have a tendency to
throw exceptions with non-helpful error messages at times. I tended to
use
a combination of Egit and the Windows Git GUI to work with Git, and used
Git at the command line when I was trying to figure out more complex
operations.
Anyway, I don't know if that came off as negative. I'm certainly not
anti-Git. If I was starting a new project, I'd most likely use Git over
SVN, and would be up for moving OpenMRS core to Git. However, just wanted
to point out that there will a learning curve and some bumps in the road,
so we should consider the pain and the opportunity cost of migration vs.
the benefits.
Take care,
Mark
________________________________________
From: [email protected] [[email protected]] On Behalf Of Darius Jazayeri [
[email protected]]
Sent: Friday, February 10, 2012 6:15 PM
To: [email protected]
Subject: Re: [OPENMRS-DEV] HTML Form Entry Sprint
I found git to be slightly more complicated than svn, but this is the
first time I've really used it, so that's to be expected.
I didn't ever create a branch, or switch between branches, since the only
big ticket I worked on was in a separate module. (And I'm sure that if I
had I'd be singing Git's praises.)
One nice thing is that it lets us avoid checking in the eclipse-specific
project files, and keeping those local.
I ran into an annoyance with the EGit plugin--the first time I did a push,
I typed the wrong password, and it has remembered it ever since, and I
couldn't figure out how to make it forget. So I haven't been able to push
from eclipse. Instead I've been using the github osx app, which is quite
nice.
-Darius
On Fri, Feb 10, 2012 at 2:14 PM, Mark Goodrich<[email protected]<mailto:
[email protected]>> wrote:
We have reached the end of the two-week HTML Form Entry sprint.
First of all, I’d like to thank everyone for their hard work and
participation… we made it though more tickets than I had anticipated, and
I
enjoyed collaborating with everybody. We have closed a total of 25
tickets
over the past two weeks, and should be closing a few more in the coming
week.
To talk about next steps… we still have 8 “in progress” tickets and 4 in
the “post-commit” stage. Some of these are on my plate, and I plan to
continue working on them next week. For anybody who still is assigned to
a
ticket that is “In Progress”, please let me know if you think you’ll still
be able to finish the ticket, and, if not, what work remains .
For those of you awaiting the next release of the module, version 1.9, my
target is to release it sometime near the end up of week of February 27th.
The delay is because I’m going to be out of the office for significant
parts of the next two weeks, and because I’d like our ace volunteer
tester,
Cordt Byrne, to do some testing further testing before release, and he is
only in the office once a week.
Also, if any of the developers would like to share their experience
working with Git, that would be much appreciates as we debate whether we
want to migrate OpenMRS core from subversion to Git.
Thanks again everyone…
Take care,
Mark
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body
(not the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
