Afternoon all, again! Sfiera already started work on his GSoC2007 project, so big woot for that! However, he committed to trunk since no decision was ever made on how GSoC work was to be coordinated. I can't stress enough how much I would prefer to see this go into a branch for itself, rather than trunk, since we'll probably have three students committing potentially unstable code to the same place at the same time. We're working with an scm system and rolling back to a working revision is always possible should anything bad happen, I know, but with so many things added it can also be a real pain (considering that some others might also commit new code/bug fixes while GSoC takes place)! Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks! Regards,... -jmpp
Hi Juan, On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Afternoon all, again! Sfiera already started work on his GSoC2007 project, so big woot for that! However, he committed to trunk since no decision was ever made on how GSoC work was to be coordinated. I can't stress enough how much I would prefer to see this go into a branch for itself, rather than trunk, since we'll probably have three students committing potentially unstable code to the same place at the same time. We're working with an scm system and rolling back to a working revision is always possible should anything bad happen, I know, but with so many things added it can also be a real pain (considering that some others might also commit new code/bug fixes while GSoC takes place)!
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks!
I'm strongly in favor of giving the GSoC students and their mentors the latitude to decide which components of their projects should be commited on a branch, and which to trunk. I believe that choice will depend on a number of factors including the nature of the change, how risky it is, how long it will take to stability, etc. In general, however, I have a preference that changes should be made on trunk unless they are destabilizing over a long period or are regarded as strictly experimental. I believe that sfiera's recent change to sqlite3 is an excellant example of something that _should_ be done on trunk: it's relatively antonymous, low-risk, and generally useful. James.
Regards,...
-jmpp
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
James Berry wrote:
I'm strongly in favor of giving the GSoC students and their mentors the latitude to decide which components of their projects should be commited on a branch, and which to trunk. I believe that choice will depend on a number of factors including the nature of the change, how risky it is, how long it will take to stability, etc. In general, however, I have a preference that changes should be made on trunk unless they are destabilizing over a long period or are regarded as strictly experimental.
I believe that sfiera's recent change to sqlite3 is an excellant example of something that _should_ be done on trunk: it's relatively antonymous, low-risk, and generally useful.
Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit. I see no harm in instructing the students to commit primarily to a branch and *then* cherry-picking out the commits that would be of immediate benefit into trunk. Cheers, -- Anant
On Jun 1, 2007, at 3:09 PM, Anant Narayanan wrote:
James Berry wrote:
I'm strongly in favor of giving the GSoC students and their mentors the latitude to decide which components of their projects should be commited on a branch, and which to trunk. I believe that choice will depend on a number of factors including the nature of the change, how risky it is, how long it will take to stability, etc. In general, however, I have a preference that changes should be made on trunk unless they are destabilizing over a long period or are regarded as strictly experimental.
I believe that sfiera's recent change to sqlite3 is an excellant example of something that _should_ be done on trunk: it's relatively antonymous, low-risk, and generally useful.
Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit.
I see no harm in instructing the students to commit primarily to a branch and *then* cherry-picking out the commits that would be of immediate benefit into trunk.
Cheers, -- Anant
Thanks for the hint Anant! Though I do not oppose jberry's argument, I believe this is yet one more reason to isolate GSoC commits in dedicated branches. Regards,... -jmpp
On 01 Jun, 2007, at 14:43, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks!
Keep in mind, one of the biggest reasons not to branch is the same reason you're encountering now: feedback. In general, I think the best solution is to work in trunk with hooks that disable the new behavior for users who aren't adventurous. That lowers the barrier for feedback, while keeping it up for safety. On 01 Jun, 2007, at 15:09, Anant Narayanan wrote:
Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit.
This should not be a problem. My project will produce a fairly sizable body of code that's completely new, which can be shown to Google. The logic to hook that code into the rest of MacPorts doesn't really need to be shown, and it would be difficult to separate this out even in a branch. Chris
On Jun 1, 2007, at 12:09 PM, Anant Narayanan wrote:
Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit.
I don't think that's true with Subversion. It's more than possible to demonstrate the changes between tags or cite specific changes by URL. Branches don't even really exist in subversion as far as that's concerned, they're just another type of tag. - Jordan
On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks!
I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor. Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against. - Jordan * Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy.
On 6/4/2007, "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks!
I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor.
Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against.
- Jordan
* Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy.)
Subversion does not currently support merge tracking (without svk), so this makes cherry picking a micromanagement burden and probably weighs in somewhat on the branching stigma as well. Only rudimentary support is targeted for Subversion 1.5, but presumably more robust by 1.6, so additionally I don't think this (merging branches back to trunk) aversion will change from that perspective anytime soon. But the lack of merge tracking is probably the only reason from the arguments I've read that I would not be quick to branch if there's reason to believe the changes are strong enough to potentially break trunk. Otherwise I have to agree with Juan that branching any potentially damaging, several revision change over time is the right way to do it. I can't see feedback as a reason to keep things in trunk anymore then I can understand third party code submittal as a reason to branch. These are existential to keeping a clean trunk. And he existing subversion feature-set lets you manage these scenarios without making implementation decisions based on outside-the-box concerns. -Mark
Mark Grimes wrote:
On 6/4/2007, "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks! I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor.
Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against.
- Jordan
* Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy.)
Subversion does not currently support merge tracking (without svk), so this makes cherry picking a micromanagement burden and probably weighs in somewhat on the branching stigma as well.
Not true. There is svnmerge.py, which makes this very easy: http://www.orcaware.com/svn/wiki/Svnmerge.py It supports cherry picking and already has most of the feature set that 1.5 will have. I would recommend using svnmerge.py to manage feature branches and it's easy to keep development on a branch that may break trunk. We use it all the time at work. Regards, Blair -- Blair Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
On 6/4/2007, "Blair Zajac" <blair@orcaware.com> wrote:
Mark Grimes wrote:
On 6/4/2007, "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks! I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor.
Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against.
- Jordan
* Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy.)
Subversion does not currently support merge tracking (without svk), so this makes cherry picking a micromanagement burden and probably weighs in somewhat on the branching stigma as well. ; Not true. There is svnmerge.py, which makes this very easy:
http://www.orcaware.com/svn/wiki/Svnmerge.py
It supports cherry picking and already has most of the feature set that 1.5 will have.
I would recommend using svnmerge.py to manage feature branches and it's easy to keep development on a branch that may break trunk. We use it all the time at work.
Regards, Blair
-- Blair Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
Maybe I'm missing something when I evaluated the tool prior to switching to svk, but my understanding is that it's better then nothing but far from a merge tracking solution as it only works at the directory level which makes microbranches a tough sell (can cause double merging). From what I've researched the consensus seems to be that you cannot merge a single file and unless you only merge from project's root every time you're stuck with manual merge tracking. I would imagine the last mile is being handled by subversion's roadmap, but I would tend to think that in large multi-developer project's something that coarse grain wouldn't be ideal. I didn't mean to slant this discussion into battle of the tools -- but what I've researched (granted opted out of) doesn't chalk svnmerge.py as a complete solution in the slightest. I'm more inclined to believe someone like yourself that has used it, but I'm pretty scared off about there being a "manual merge tracking" path at all when it comes to making decisions about being quick to branch or not. I've always been quick to branch because svk does a very nice job of this whilest keeping my sanity entact, but my scorecard only shows 2 committers using svk thus far, so I wanted to bring up subversion's work-in-progress on the technical slant. Noone needs the headache of branching if the technical merging is not up to par with what people envision they can do. You don't find that many subversion projects that are branch happy, but I'm not necessarily convinced it is because of JKH's reasons as much as it is an implementation pitfall and known weakness on the Subversion side that are currently being milestoned (http://subversion.tigris.org/merge-tracking/) -Mark
Mark Grimes wrote:
On 6/4/2007, "Blair Zajac" <blair@orcaware.com> wrote:
Mark Grimes wrote:
On 6/4/2007, "Jordan K. Hubbard" <jkh@brierdr.com> wrote:
On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks! I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor.
Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against.
- Jordan
* Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy.) Subversion does not currently support merge tracking (without svk), so this makes cherry picking a micromanagement burden and probably weighs in somewhat on the branching stigma as well. ; Not true. There is svnmerge.py, which makes this very easy:
http://www.orcaware.com/svn/wiki/Svnmerge.py
It supports cherry picking and already has most of the feature set that 1.5 will have.
I would recommend using svnmerge.py to manage feature branches and it's easy to keep development on a branch that may break trunk. We use it all the time at work.
Regards, Blair
-- Blair Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
Maybe I'm missing something when I evaluated the tool prior to switching to svk, but my understanding is that it's better then nothing but far from a merge tracking solution as it only works at the directory level which makes microbranches a tough sell (can cause double merging). From what I've researched the consensus seems to be that you cannot merge a single file and unless you only merge from project's root every time you're stuck with manual merge tracking.
Yes, that's true, but for this type of work, I don't see very often merging on the file level. Maybe that's a limitation of the tool, but I typically see merges at the directory level and of complete revisions.
I would imagine the last mile is being handled by subversion's roadmap, but I would tend to think that in large multi-developer project's something that coarse grain wouldn't be ideal.
I didn't mean to slant this discussion into battle of the tools -- but what I've researched (granted opted out of) doesn't chalk svnmerge.py as a complete solution in the slightest.
I think you're being a little dismissive here. For 90% of the merging people do, merging complete revisions and at a top level directory is sufficient. We're not talking about the big project here for MacPorts. We use svnmerge.py in the Subversion project itself on feature branches. Here, most of the time you want to just merge changes from trunk into the feature branch en-masse to keep the branch up to date and not have to keep track of what you have already merged over. When the branch work is ready, you merge it by hand back into trunk. I don't see this being much different for a MacPorts feature branch. So svnmerge.py works fine here.
I'm more inclined to believe someone like yourself that has used it, but I'm pretty scared off about there being a "manual merge tracking" path at all when it comes to making decisions about being quick to branch or not. I've always been quick to branch because svk does a very nice job of this whilest keeping my sanity entact, but my scorecard only shows 2 committers using svk thus far, so I wanted to bring up subversion's work-in-progress on the technical slant. Noone needs the headache of branching if the technical merging is not up to par with what people envision they can do. You don't find that many subversion projects that are branch happy, but I'm not necessarily convinced it is because of JKH's reasons as much as it is an implementation pitfall and known weakness on the Subversion side that are currently being milestoned (http://subversion.tigris.org/merge-tracking/)
-Mark
I use svk also, but more for having a copy of a repository on my laptop and being able to do commits then for its merge tracking. We use branches at work all the time. Each developer gets their own branch and we use trunk to track what's in production web site (Java, HTML code). So we do svnmerge.py merges from trunk into each developers branch when they want to, and also use svnmerge.py for merge from the developer's branch back into trunk for when new code is being deployed. In this case, svnmerge.py does all we need. Does svk support more fine grained branch management where the branches live on the server and not in ~/.svk? Regards, Blair
Jordan K. Hubbard wrote:
On Jun 1, 2007, at 12:09 PM, Anant Narayanan wrote:
Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit.
I don't think that's true with Subversion. It's more than possible to demonstrate the changes between tags or cite specific changes by URL. Branches don't even really exist in subversion as far as that's concerned, they're just another type of tag.
Actually, it's better to think about tags as a type of branch where you agree not to make commits on the tag after you create it. Regards, Blair
On Mon, 04 Jun 2007 17:25:13 -0700, Blair Zajac wrote:
Mark Grimes wrote:
On 6/4/2007, "Blair Zajac" <blair@orcaware.com> wrote: I would imagine the last mile is being handled by subversion's roadmap, but I would tend to think that in large multi-developer project's something that coarse grain wouldn't be ideal.
I didn't mean to slant this discussion into battle of the tools -- but what I've researched (granted opted out of) doesn't chalk svnmerge.py as a complete solution in the slightest.
I think you're being a little dismissive here. For 90% of the merging people do, merging complete revisions and at a top level directory is sufficient.
Ya I most certainly am being dismissive, it's not on purpose it's easy to lose sight on where svk extends svn, as for years svk has vested energy on exactly this problem -- svk's no-brainer merge tracking has saved my bacon more then a few times, simply because a small contingent of developers I work with are branch happy while the rest don't acknowledge there is anything but trunk (both dangerous, but the former shouldn't be... or at least living with the others that are branch happy shouldn't be) I think it's more of a question of where you want to spend your time and not "can from can't do", which is the attitude I think I originally aired. Of course you can do it... but wouldn't you rather be focused on content then playing chess with your version control system. I'd have a general fear of branching with svn a la carte, but thanks for the tip on svnmerge.py, I should reinvestigate it for the colleagues that don't listen to my thunderous svk advocacy in the hallways at the office. ;)
We're not talking about the big project here for MacPorts. We use svnmerge.py in the Subversion project itself on feature branches. Here, most of the time you want to just merge changes from trunk into the feature branch en-masse to keep the branch up to date and not have to keep track of what you have already merged over. When the branch work is ready, you merge it by hand back into trunk.
Yeah if you don't care about double merging nor evil twins that is. Unfortunately, evil twins have bit me all over the place in svn a la carte.
I use svk also, but more for having a copy of a repository on my laptop and being able to do commits then for its merge tracking.
The decentralization is just the most recognized feature, it's certainly not the most powerful. When 2.0 was cut at the beginning of 2007, things got significantly more impressive on a few fronts (http://bestpractical.typepad.com/worst_impractical/2007/01/svk_20_is_bette.h...)
We use branches at work all the time. Each developer gets their own branch and we use trunk to track what's in production web site (Java, HTML code). So we do svnmerge.py merges from trunk into each developers branch when they want to, and also use svnmerge.py for merge from the developer's branch back into trunk for when new code is being deployed.
Sounds like an architectural design crafted around coarse grain merge tracking. At my work, we create functional branches that >1 people play in. Without fine grain merge tracking it is hard to divvy up the merges between developers... it does seem like the svn players in our repos are afraid to branch, maybe from fear that the tree will diverge too much from any lengthy work in a branch. Who can blame them, especially when the trees themselves are not very atomic with respect to control of what other developers are doing. There are countless examples of evil twin problems, and in general it's hard to merge by hand when you can't control other users that may be doing more immediate merges between branches.
In this case, svnmerge.py does all we need.
Does svk support more fine grained branch management where the branches live on the server and not in ~/.svk?
You are still doing your work against a mirrored path that throws svk:merge tickets all over macports directory structure, so I don't see this as acting any different then dealing with local branches that offer the same merge ticket system. svk can inspect remotely mirrored svk:merge tickets on the macports tree just the same, so I would gather your granularity is at the same level. If you want to pull local branch management out of the loop, engage all your svk commands against the mirrored path and that would basically give you "svn" + merge tracking via tickets. This is not a way I've ever operated, but I suppose it's completely conceivable since the merge tickets litter the server svn repo as props. Tying the fun tangent back to GSoC, it sounds like it [GSoC] being more or less a student exercise then pair programming would benefit from svnmerge.py or coarse grain merge tracking if branching is warranted or even used discretionarily. -Mark
participants (7)
-
Anant Narayanan
-
Blair Zajac
-
Chris Pickel
-
James Berry
-
Jordan K. Hubbard
-
Juan Manuel Palacios
-
Mark Grimes