Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
As sf.net has gained support for Git recently, this brought me to obvious question - how about to migrate to it? The migration of data from SVN is quite easy, so this should not be the issue. But the question is whether some of you know Git or are willing to learn it.
Michal Čihař a écrit :
Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
As sf.net has gained support for Git recently, this brought me to obvious question - how about to migrate to it? The migration of data from SVN is quite easy, so this should not be the issue. But the question is whether some of you know Git or are willing to learn it.
Hi Michal, I would say that the question is not about "some of you"; we must decide this, based on the majority of people who are currently submitting SVN patches. I would not like them to be dissuaded to contribute.
For me, I don't use git and am not sure that we would need its features very often; also, for the next GSoC we can plan things differently, looking how to improve work with branches.
Hi
Dne Fri, 21 Aug 2009 08:04:16 -0400 Marc Delisle marc@infomarc.info napsal(a):
I would say that the question is not about "some of you"; we must decide this, based on the majority of people who are currently submitting SVN patches. I would not like them to be dissuaded to contribute.
Well I'd not say this is is about the decision, but rather testing whether there would be interest into doing such thing. If more people would be interested in this, it could push others to learn it. On the other side if nobody except me sees advantage in such change, I'm not going to spend my time on pushing it.
For me, I don't use git and am not sure that we would need its features very often; also, for the next GSoC we can plan things differently, looking how to improve work with branches.
Well there are more things where it might be helpful (eg. making changes in more branches, what is right now basically manual work). Or just it does not have some problems (as you do most things locally, it is generally much faster and you are not doomed when server is badly reachable because it is heavy loaded).
What I really hate in last days is that just svn update of my phpmyadmin tree takes several minutes. Having fast computer and fast internet access, such operation should be fast as well.
If you want to read some more differences you can read here:
http://git.or.cz/gitwiki/GitSvnComparsion
To see how to control git and how it differs from svn:
http://git.or.cz/course/svn.html
And finally if you want to spend several evenings by reading a git book :-):
Michal Čihař a écrit :
Hi
What I really hate in last days is that just svn update of my phpmyadmin tree takes several minutes. Having fast computer and fast internet access, such operation should be fast as well.
My working copy does not contain the full tree, it only has some parts that I find useful; for me, svn update takes a few seconds. OK I'm in Canada but what about svn update times for other Europe-based developers?
Hi
Dne Fri, 21 Aug 2009 13:32:05 -0400 Marc Delisle marc@infomarc.info napsal(a):
What I really hate in last days is that just svn update of my phpmyadmin tree takes several minutes. Having fast computer and fast internet access, such operation should be fast as well.
My working copy does not contain the full tree, it only has some parts that I find useful; for me, svn update takes a few seconds. OK I'm in Canada but what about svn update times for other Europe-based developers?
Well I used to have also parts, but needing QA branches time to time, now the gsoc branches, documentation, website ... I basically have full copy.
Anyway right now it takes about 20 seconds to do svn update on up to date tree. This afternoon it was 3 minutes. It just depends how heavy loaded the server is. And it looks to me like it is usually heavy loaded in times when I work ;-).
Michal Čihař a écrit :
Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
About Subversion 1.6 branching and merging: http://www.phpcult.com/blog/2009/08/subversion-1-6-branching-and-merging-cav...
As sf.net has gained support for Git recently, this brought me to obvious question - how about to migrate to it? The migration of data from SVN is quite easy, so this should not be the issue. But the question is whether some of you know Git or are willing to learn it.
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Marc Delisle wrote:
Michal Čihař a écrit :
Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
About Subversion 1.6 branching and merging: http://www.phpcult.com/blog/2009/08/subversion-1-6-branching-and-merging-cav...
I'm sort-off back... but still catching up on some reading.
As the link above points out it has become a bit easier to do merging in svn 'recently'. A while back when I was experimenting with git I noticed that svn now stores a property to keep track of which trunk changes have already been merged into your branch. After bringing your branch into sync, which is not limited to a single time, merging into trunk should be straightforward.
My point being: The tools are more important then the architecture.
Sure git has some very nice advantages, mainly being less reliant on the 'slow' sf.net svn server. But many users have svn experience and speaking for myself limited git experience.
Either way is fine by me, I don't mind reading up on git.
Hey all,
I figured I'd put in my two cents now that I've had a summer full of experience dealing with branches in SVN...
On Fri, Aug 21, 2009 at 12:25 PM, Herman van Rinkrink@initfour.nl wrote:
Marc Delisle wrote:
Michal Čihař a écrit :
Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
About Subversion 1.6 branching and merging: http://www.phpcult.com/blog/2009/08/subversion-1-6-branching-and-merging-cav...
I have SVN 1.6.4, and tried to merge my branch back into the trunk with that method, as well as any others I could find, and I still ended up doing it manually. Therefore, I know I was using the correct commands/syntax to merge it back (I used methods listed for 1.6 all the way back to 1.0, I believe), so the problem was either SVN or I set my branch up wrong (I used SVN copy, and from all I could find this is the correct way). Not quite sure what to make of it.
For what it's worth, keeping my branch in sync with the trunk was incredibly easy, so SVN does have that going for it.
I'm sort-off back... but still catching up on some reading.
As the link above points out it has become a bit easier to do merging in svn 'recently'. A while back when I was experimenting with git I noticed that svn now stores a property to keep track of which trunk changes have already been merged into your branch. After bringing your branch into sync, which is not limited to a single time, merging into trunk should be straightforward.
My point being: The tools are more important then the architecture.
Sure git has some very nice advantages, mainly being less reliant on the 'slow' sf.net svn server. But many users have svn experience and speaking for myself limited git experience.
Either way is fine by me, I don't mind reading up on git.
After doing some preliminary reading, git does look promising. I don't have any problem learning the new system (it appears rather straight-forward, from what I have seen so far). Count me in if we feel there to be enough of a benefit over SVN.
-- Met vriendelijke groet / Regards,
Herman van Rink Initfour websolutions
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Fri, 21 Aug 2009 11:21:12 -0400 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi all
while merging GSoC branches, I really understood how painful are branches in SVN. I use Git for most other projects and such thing is much easier there as well as it adds some other benefits (eg. possibility to work offline).
About Subversion 1.6 branching and merging: http://www.phpcult.com/blog/2009/08/subversion-1-6-branching-and-merging-cav...
Well for some reason merging gsoc branches back to trunk did not work this way. Even though I merged all changes to other branch before so it was just about applying diff between branch and trunk (what I did manually at the end). Maybe I just did something wrong...
-
Derek Schaefer -
Herman van Rink -
Marc Delisle -
Michal Čihař