Hi all!
I just heard the great news! Thanks for giving me this opportunity again! Congratulations Felipe, Marco, Jasper and Max! Special note to Max and Marco: since you do geometry things, I'd be happy to work more closely with you if possible and desired :) To Jasper: is it okay if I bug you about path tests? :) Really excited by the project ideas that were accepted! Now, to the topic of this mail: GSoC branches, yes/no.
I will be doing under-the-hood refactoring, and I am thinking about whether or not to work in my own svn branch. Pros: I can break builds with partial commits and/or make bad bad bugs. Cons: I won't discover bad bugs.
I'd like to work in trunk, because of the bugs issue and because it will force me to immediately handle new code by others. Moreover, I will be forced to make changes that build and function and won't be drawn into making a half-way solution that will not work at the end of GSOC.
For the people that are afraid I will be messing up trunk badly: I first intend to do changes in the way the code accesses the path data, then make a test function for conversion to 2geom, then have both representations in inkscape at the same time and constantly check whether they are the same, etc. I intend to do small steps towards completely going to 2geom, so I am more sure that it actually works and did not introduce new bugs.
Please let me know what you think of this.
Cheers! Johan
J.B.C.Engelen@...1578... wrote:
Hi all!
I just heard the great news! Thanks for giving me this opportunity again! Congratulations Felipe, Marco, Jasper and Max!
Indeed, and to you as well.
Special note to Max and Marco: since you do geometry things, I'd be happy to work more closely with you if possible and desired :) To Jasper: is it okay if I bug you about path tests? :)
Sure :)
Really excited by the project ideas that were accepted! Now, to the topic of this mail: GSoC branches, yes/no.
I will be doing under-the-hood refactoring, and I am thinking about whether or not to work in my own svn branch. Pros: I can break builds with partial commits and/or make bad bad bugs. Cons: I won't discover bad bugs.
I'd like to work in trunk, because of the bugs issue and because it will force me to immediately handle new code by others. Moreover, I will be forced to make changes that build and function and won't be drawn into making a half-way solution that will not work at the end of GSOC.
Sounds sensible to me. After all, when refactoring you should indeed be aiming to keep the code working after every step.
BTW, I had a look at path handling in Inkscape recently (because of my relative paths patch) and I encountered the following parts of the code that deal with paths (you probably already know most, if not all, of this, but I thought I'd list it anyway, just in case): - NR::Path, libnr/n-art-bpath - libnr/n-art-bpath-2geom - svg/gnome-canvas-bpath-util, svg/svg-path, svg/path-string - SP::Curve - Geom::Path - livarot Path(Descr) - dom/svgtypes SP::Curve, NR::Path and Geom::Path probably have the most functionality in common. The livarot Path(Descr) class(es) are also similar, but they also have a lot of rendering related functionality. n-art-bpath-2geom and the svg/* files on the other hand all do something with parsing/serializing. And dom/svgtypes is probably again a completely different story, but looking at the file(s) I do wonder whether it couldn't reuse a bit more (in general, not just the path related parts).
On Tue, 22 Apr 2008 10:04:16 +0200, <J.B.C.Engelen@...1578...> wrote:
Hi all!
I just heard the great news! Thanks for giving me this opportunity again! Congratulations Felipe, Marco, Jasper and Max! Special note to Max and Marco: since you do geometry things, I'd be happy to work more closely with you if possible and desired :) To Jasper: is it okay if I bug you about path tests? :) Really excited by the project ideas that were accepted!
Hi Johan! Congratulations to you as well! You can rely on my collaboration in your refactoring task! And the same is true for Max project, too.
skip
For the people that are afraid I will be messing up trunk badly: I first intend to do changes in the way the code accesses the path data, then make a test function for conversion to 2geom, then have both representations in inkscape at the same time and constantly check whether they are the same, etc. I intend to do small steps towards completely going to 2geom, so I am more sure that it actually works and did not introduce new bugs.
Please let me know what you think of this.
It sounds good for me. It seems to me that you have to take the right precautions on your mind, so you can commit into trunk directly.
Cheers, Marco
PS: have you a gmail account that you check for IM ?
On Tue, Apr 22, 2008 at 10:04:16AM +0200, J.B.C.Engelen@...1578... wrote:
I will be doing under-the-hood refactoring, and I am thinking about whether or not to work in my own svn branch. Pros: I can break builds with partial commits and/or make bad bad bugs. Cons: I won't discover bad bugs.
Well, no doubt some bugs will be evident from mere "smoke testing". "Discover[y of] bad bugs" is of course also the other half of "breaking things for users": more specifically, using trunk doesn't get the advantage of discovering bad bugs except by breaking things for users.
I'd like to work in trunk, because of the bugs issue and because it will force me to immediately handle new code by others.
Re immediately handling code newly added to trunk, I was hoping that svn would make it easy to "re-root" / re-seat / re-target a branch, i.e. "move/adapt the branch" to a different split point. I believe that BitKeeper had this as a goal, and consequently I hoped that git and possibly even svn would do so. At the least I suppose it should be possible to do so semi-manually, i.e. to create a version that's the merge of splitpt:trunk-head and splitpt:branch-head, and create a new branch from this.
If svn doesn't make it convenient to keep a branch up-to-date with HEAD then perhaps should use git-svn, bzr-svn or the like?
Moreover, I will be forced to make changes that build and function and won't be drawn into making a half-way solution that will not work at the end of GSOC.
There is that psychological "advantage" if you trust your current judgement over your future judgement about the trade-offs involved in the extra work of making things less likely to have bugs or more generally palettable for trunk in exchange for making it more likely that something will be left in trunk at the end of GSoC. I'll note that future judgements will be more informed about the specifics of the situation, though I haven't thought about the psychological effects that might bias future decisions towards the wrong decision.
I expect that some of the intermediate steps in the transformation involved in JohanE's project in particular will be net regressions in terms of performance and messages to stderr (warnings of possible bugs).
The matter of what goes into trunk and when may be influenced on what improvements are available from a project when it is only part-way finished.
pjrm.
I really, really, really strongly believe we shouldn't do branches unless we use a dscm like bzr to do it. SVN makes frequent integration painful, but frequent integration is the only way to keep things from diverging horribly in the long run.
Via launchpad, we do already have a bzr mirror which tracks trunk that people can clone from, so there is no technical obstacle to using bzr at this point. The main missing piece is that I'd like to see a way to push commits back up to SVN from bzr, like you can with git. (In the worst case you can simply extract a changeset as a patch and do things that way, however.)
-mental
Maybe I thought too quick about it. I think I'll work in my own branch, but perhaps every now and then push things that work to trunk?
Last year I had LPE in a branch and it was easy to keep it up to date with trunk; which I did very regularly.
SVN makes frequent integration painful
It would be nice to be able to do it with one push of the button, but I had no particular hard time last year (with Tortoise, it's maybe pushing 5 buttons).
I think Peter is right about me better not working in trunk. The 'bad bugs' argument to me actually sounds in favor of using a branch, because I like to keep trunk useable and only a slight bit more buggy than release (or maybe even less buggy).
Thanks,
Johan
-----Original Message----- From: MenTaLguY [mailto:mental@...3...] Sent: dinsdag 22 april 2008 19:32 To: Engelen, J.B.C. (Johan); bryce@...1798... Cc: inkscape-devel@lists.sourceforge.net; Peter.Moulder@...38... Subject: Re: [Inkscape-devel] GSOC branches
I really, really, really strongly believe we shouldn't do branches unless we use a dscm like bzr to do it. SVN makes frequent integration painful, but frequent integration is the only way to keep things from diverging horribly in the long run.
Via launchpad, we do already have a bzr mirror which tracks trunk that people can clone from, so there is no technical obstacle to using bzr at this point. The main missing piece is that I'd like to see a way to push commits back up to SVN from bzr, like you can with git. (In the worst case you can simply extract a changeset as a patch and do things that way, however.)
-mental
On Tue, Apr 22, 2008 at 07:45:14PM +0200, J.B.C.Engelen@...1578... wrote:
I think Peter is right about me better not working in trunk.
Fwiw, I didn't actually suggest a particular conclusion, even if most of the arguments I advanced were for working with a branch [which isn't quite the same as not working in trunk: as you say, one can work mainly in a branch but still copy things to trunk as they become ready].
pjrm.
On Tue, Apr 22, 2008 at 10:31:34AM -0700, MenTaLguY wrote:
I really, really, really strongly believe we shouldn't do branches unless we use a dscm like bzr to do it. SVN makes frequent integration painful, but frequent integration is the only way to keep things from diverging horribly in the long run.
Via launchpad, we do already have a bzr mirror which tracks trunk that people can clone from, so there is no technical obstacle to using bzr at this point. The main missing piece is that I'd like to see a way to push commits back up to SVN from bzr, like you can with git. (In the worst case you can simply extract a changeset as a patch and do things that way, however.)
I gather this could be done with bzr-svn, but the launchpad bzr mirror is one way currently.
However, for purposes of frequent integration that's not so bad - at least the students can keep up to tip while working, and send diffs in as they're ready.
A "GSoC" staging branch to merge in all the students work into bzr might also be nice to make it easier for mentors and others to test and track the combined work of the students during development.
Bryce
On Tue, 22 Apr 2008 15:03:29 -0700, Bryce Harrington <bryce@...1798...> wrote:
I gather this could be done with bzr-svn, but the launchpad bzr mirror is one way currently.
It shouldn't be necessary to have a two-way mirror (I don't need one with git). All that's required is to be able to take a changeset from a bzr repository and merge it to SVN locally using bzr-svn, in hopefully something resembling the normal bzr fashion.
However, for purposes of frequent integration that's not so bad - at least the students can keep up to tip while working, and send diffs in as they're ready.
A "GSoC" staging branch to merge in all the students work into bzr might also be nice to make it easier for mentors and others to test and track the combined work of the students during development.
For the sake of the students might it be simpler for them to have a single "upstream"? (whether trunk, or a GSoC staging branch that is loosely synced with trunk)
-mental
J.B.C.Engelen@...1578... schrieb:
I just heard the great news! Thanks for giving me this opportunity again!
I'm equally grateful and thrilled. Many thanks to everyone involved!
Congratulations Felipe, Marco, Jasper and Max! Special note to Max and Marco: since you do geometry things, I'd be happy to work more closely with you if possible and desired :)
Absolutely. :) I was about to propose the same, since I'm sure I can benefit a lot from your knowledge of LPEs. I also already have a few questions concerning the migration of path representations to 2geom.
@everyone: As mentioned before, I'm going to remain pretty silent during the next 3 weeks due to my last graduation exam. As soon as that is done, I can entirely focus on GSoC. :)
Cheers and thanks again, Max
participants (7)
-
unknown＠example.com -
Bryce Harrington -
Jasper van de Gronde -
Marco -
Maximilian Albert -
MenTaLguY -
Peter Moulder