You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by dcz <dc...@phpbb-seo.com> on 2010/02/17 13:17:12 UTC
Junior developers
Hello,
Here is what I'm trying to do : some user (let's call them junior
developer) should require their commit to be authorized by other (senior
developer) before they would actually be committed.
Since I saw this feature on an svn (though I do not administrate this
one, so I can't tell how it is done, but it's svn for sure) and found it
pretty useful, I was a bit surprised not to be able to find any topic
about it after hours a googling.
Would be very nice if someone could share thoughts about how to set such
feature up.
Regards,
dcz
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 17/02/2010 18:34, Ryan Schmidt a écrit :
> On Feb 17, 2010, at 08:36, dcz wrote:
>
>
>> Le 17/02/2010 15:24, Andy Levy a écrit :
>>
>>>
>>
>>> There is no "dry run" for a commit. It's conceivable that you could
>>> check the user ID in the pre-commit, and if the committer is JD,
>>> reject the commit while mailing a diff to SD which represents the
>>> change being attempted. This would require a lot of overhead on the
>>> server though.
>>>
>>> Honestly, I think you're trying to apply an excessively technical
>>> solution to a fundamentally non-technical idea.
>>>
>>>
>> You're probably right, I was just thinking that a bit more automation could be handy.
>> Though solution 1) is very close to do it, could use a mailing list to warn all SD at a time and see who handles first.
>> I would just have liked to skip the JD "putting together a patch" step and have it done by the server, but ho well.
>>
> I think it would be easy -- for the server or the JD manually -- to put together a patch -- it's simply:
>
> svn di> patchfile
>
> It could even be mailed to the SD straightaway:
>
> svn di | mail sd@example.com
>
>
> You could try to build this into the pre-commit script, but I'd think the JD would start getting annoyed that his patch review process keeps giving him negative feedback by telling him "Your commit was rejected with the following message" (or whatever the verbiage is that Subversion prints out). I'd also say it's confusing that the JD has to run "svn commit" when he's not really committing anything to the repository. Instead I'd suggest you write a new script, call it svnreview.sh or something, and have the JD run that instead. This script runs "svn di", maybe some other sanity checks first, then sends the email.
>
>
Hello,
I just need time to look into svn hooks a bit more.
As dumb as it seems, I did not think about this as code review yet, I
was struck with the perm / auth concept while searching. Your phrasing
made me find few more things I may also have to consider :
http://ostatic.com/blog/open-source-code-review-tools
Did anyone of you tried on of those with svn yet ?
From what I've read so far, it seems that "review board" may be able to
do such thing :
http://www.reviewboard.org/docs/manual/dev/faq/#what-are-pre-commit-and-post-commit-reviews
"Pre-commit reviews are where code is reviewed before it’s checked into
a public repository and mainline, non-developer branch. Code isn’t
committed until reviewers sign off on it, leaving the tree stable and
easing changes."
I already use redmine to handle a dev team
(http://phpbb-seo.coda-cola.net/), and find it handy especially since
www.coda-cola.net is offering hosting for it (with the backup /
maintenance harassement), but after I makes things a bit clearer about
review board, I may convince them to add it or just install it myself
somewhere else as a pre commit only tool.
I'll keep you in touch, meanwhile, if you have thoughts about this, do
not hesitate to share ;-)
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 17/02/2010 18:34, Ryan Schmidt a écrit :
> On Feb 17, 2010, at 08:36, dcz wrote:
>
>
>> Le 17/02/2010 15:24, Andy Levy a écrit :
>>
>>>
>>
>>> There is no "dry run" for a commit. It's conceivable that you could
>>> check the user ID in the pre-commit, and if the committer is JD,
>>> reject the commit while mailing a diff to SD which represents the
>>> change being attempted. This would require a lot of overhead on the
>>> server though.
>>>
>>> Honestly, I think you're trying to apply an excessively technical
>>> solution to a fundamentally non-technical idea.
>>>
>>>
>> You're probably right, I was just thinking that a bit more automation could be handy.
>> Though solution 1) is very close to do it, could use a mailing list to warn all SD at a time and see who handles first.
>> I would just have liked to skip the JD "putting together a patch" step and have it done by the server, but ho well.
>>
> I think it would be easy -- for the server or the JD manually -- to put together a patch -- it's simply:
>
> svn di> patchfile
>
> It could even be mailed to the SD straightaway:
>
> svn di | mail sd@example.com
>
>
> You could try to build this into the pre-commit script, but I'd think the JD would start getting annoyed that his patch review process keeps giving him negative feedback by telling him "Your commit was rejected with the following message" (or whatever the verbiage is that Subversion prints out). I'd also say it's confusing that the JD has to run "svn commit" when he's not really committing anything to the repository. Instead I'd suggest you write a new script, call it svnreview.sh or something, and have the JD run that instead. This script runs "svn di", maybe some other sanity checks first, then sends the email.
>
>
Hello,
I just need time to look into svn hooks a bit more.
As dumb as it seems, I did not think about this as code review yet, I
was struck with the perm / auth concept while searching. Your phrasing
made me find few more things I may also have to consider :
http://ostatic.com/blog/open-source-code-review-tools
Did anyone of you tried on of those with svn yet ?
From what I've read so far, it seems that "review board" may be able to
do such thing :
http://www.reviewboard.org/docs/manual/dev/faq/#what-are-pre-commit-and-post-commit-reviews
"Pre-commit reviews are where code is reviewed before it’s checked into
a public repository and mainline, non-developer branch. Code isn’t
committed until reviewers sign off on it, leaving the tree stable and
easing changes."
I already use redmine to handle a dev team
(http://phpbb-seo.coda-cola.net/), and find it handy especially since
www.coda-cola.net is offering hosting for it (with the backup /
maintenance harassement), but after I makes things a bit clearer about
review board, I may convince them to add it or just install it myself
somewhere else as a pre commit only tool.
I'll keep you in touch, meanwhile, if you have thoughts about this, do
not hesitate to share ;-)
Re: Junior developers
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 17, 2010, at 08:36, dcz wrote:
> Le 17/02/2010 15:24, Andy Levy a écrit :
>>
>
>> There is no "dry run" for a commit. It's conceivable that you could
>> check the user ID in the pre-commit, and if the committer is JD,
>> reject the commit while mailing a diff to SD which represents the
>> change being attempted. This would require a lot of overhead on the
>> server though.
>>
>> Honestly, I think you're trying to apply an excessively technical
>> solution to a fundamentally non-technical idea.
>>
>
> You're probably right, I was just thinking that a bit more automation could be handy.
> Though solution 1) is very close to do it, could use a mailing list to warn all SD at a time and see who handles first.
> I would just have liked to skip the JD "putting together a patch" step and have it done by the server, but ho well.
I think it would be easy -- for the server or the JD manually -- to put together a patch -- it's simply:
svn di > patchfile
It could even be mailed to the SD straightaway:
svn di | mail sd@example.com
You could try to build this into the pre-commit script, but I'd think the JD would start getting annoyed that his patch review process keeps giving him negative feedback by telling him "Your commit was rejected with the following message" (or whatever the verbiage is that Subversion prints out). I'd also say it's confusing that the JD has to run "svn commit" when he's not really committing anything to the repository. Instead I'd suggest you write a new script, call it svnreview.sh or something, and have the JD run that instead. This script runs "svn di", maybe some other sanity checks first, then sends the email.
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 17/02/2010 15:24, Andy Levy a écrit :
> On Wed, Feb 17, 2010 at 09:19, dcz<dc...@phpbb-seo.com> wrote:
>
>> Thanks for responding.
>>
>> I was hopping that someone did put something together to handle this.
>> It looks like doable with a pre-commit hook that would have a look in a db
>> (or a file) to find out if the user is JD or SD. For JDs, the commit could
>> be made dry-run, and the script could in such case send a mail to SDs who
>> could later reply to in order to do the actual commit (eg authorize it), or
>> not.
>>
> Hook scripts do not work in this way. They are non-interactive and
> especially in the case of the pre-commit, will block others from
> committing while the hook is executing.
>
> There is no "dry run" for a commit. It's conceivable that you could
> check the user ID in the pre-commit, and if the committer is JD,
> reject the commit while mailing a diff to SD which represents the
> change being attempted. This would require a lot of overhead on the
> server though.
>
> Honestly, I think you're trying to apply an excessively technical
> solution to a fundamentally non-technical idea.
>
>
You're probably right, I was just thinking that a bit more automation
could be handy.
Though solution 1) is very close to do it, could use a mailing list to
warn all SD at a time and see who handles first.
I would just have liked to skip the JD "putting together a patch" step
and have it done by the server, but ho well.
Thanks for sharing your thoughs.
>> Unfortunately, I still have a lot of doc to read about svn and not so much
>> time as us all.
>> But since I saw it working, I keep faith ;-)
>>
>>
>>
>> Le 17/02/2010 14:30, Andy Levy a écrit :
>>
>>> On Wed, Feb 17, 2010 at 08:17, dcz<dc...@phpbb-seo.com> wrote:
>>>
>>>
>>>> Hello,
>>>> Here is what I'm trying to do : some user (let's call them junior
>>>> developer)
>>>> should require their commit to be authorized by other (senior developer)
>>>> before they would actually be committed.
>>>>
>>>> Since I saw this feature on an svn (though I do not administrate this
>>>> one,
>>>> so I can't tell how it is done, but it's svn for sure) and found it
>>>> pretty
>>>> useful, I was a bit surprised not to be able to find any topic about it
>>>> after hours a googling.
>>>>
>>>> Would be very nice if someone could share thoughts about how to set such
>>>> feature up.
>>>>
>>>>
>>> Subversion has no such feature, which is why you can't find anything about
>>> it.
>>>
>>> You can approach this a couple of ways. 2 that come to mind immediately:
>>> 1) Junior developer (JD) submits patches to the senior developer (SD).
>>> SD reviews the patch& commits when he's satisfied.
>>> 2) JD gets his own private branch& can commit to it all day long.
>>> When he's ready for a code review, SD looks it over& merges JD's work
>>> into trunk (or wherever your main development is done). This will
>>> require that JD's branch be kept up to date with regular merges from
>>> trunk so that he's not conflicting with other peoples' work.
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 17/02/2010 15:24, Andy Levy a écrit :
> On Wed, Feb 17, 2010 at 09:19, dcz<dc...@phpbb-seo.com> wrote:
>
>> Thanks for responding.
>>
>> I was hopping that someone did put something together to handle this.
>> It looks like doable with a pre-commit hook that would have a look in a db
>> (or a file) to find out if the user is JD or SD. For JDs, the commit could
>> be made dry-run, and the script could in such case send a mail to SDs who
>> could later reply to in order to do the actual commit (eg authorize it), or
>> not.
>>
> Hook scripts do not work in this way. They are non-interactive and
> especially in the case of the pre-commit, will block others from
> committing while the hook is executing.
>
> There is no "dry run" for a commit. It's conceivable that you could
> check the user ID in the pre-commit, and if the committer is JD,
> reject the commit while mailing a diff to SD which represents the
> change being attempted. This would require a lot of overhead on the
> server though.
>
> Honestly, I think you're trying to apply an excessively technical
> solution to a fundamentally non-technical idea.
>
>
You're probably right, I was just thinking that a bit more automation
could be handy.
Though solution 1) is very close to do it, could use a mailing list to
warn all SD at a time and see who handles first.
I would just have liked to skip the JD "putting together a patch" step
and have it done by the server, but ho well.
Thanks for sharing your thoughs.
>> Unfortunately, I still have a lot of doc to read about svn and not so much
>> time as us all.
>> But since I saw it working, I keep faith ;-)
>>
>>
>>
>> Le 17/02/2010 14:30, Andy Levy a écrit :
>>
>>> On Wed, Feb 17, 2010 at 08:17, dcz<dc...@phpbb-seo.com> wrote:
>>>
>>>
>>>> Hello,
>>>> Here is what I'm trying to do : some user (let's call them junior
>>>> developer)
>>>> should require their commit to be authorized by other (senior developer)
>>>> before they would actually be committed.
>>>>
>>>> Since I saw this feature on an svn (though I do not administrate this
>>>> one,
>>>> so I can't tell how it is done, but it's svn for sure) and found it
>>>> pretty
>>>> useful, I was a bit surprised not to be able to find any topic about it
>>>> after hours a googling.
>>>>
>>>> Would be very nice if someone could share thoughts about how to set such
>>>> feature up.
>>>>
>>>>
>>> Subversion has no such feature, which is why you can't find anything about
>>> it.
>>>
>>> You can approach this a couple of ways. 2 that come to mind immediately:
>>> 1) Junior developer (JD) submits patches to the senior developer (SD).
>>> SD reviews the patch& commits when he's satisfied.
>>> 2) JD gets his own private branch& can commit to it all day long.
>>> When he's ready for a code review, SD looks it over& merges JD's work
>>> into trunk (or wherever your main development is done). This will
>>> require that JD's branch be kept up to date with regular merges from
>>> trunk so that he's not conflicting with other peoples' work.
>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Junior developers
Posted by Andy Levy <an...@gmail.com>.
On Wed, Feb 17, 2010 at 09:19, dcz <dc...@phpbb-seo.com> wrote:
> Thanks for responding.
>
> I was hopping that someone did put something together to handle this.
> It looks like doable with a pre-commit hook that would have a look in a db
> (or a file) to find out if the user is JD or SD. For JDs, the commit could
> be made dry-run, and the script could in such case send a mail to SDs who
> could later reply to in order to do the actual commit (eg authorize it), or
> not.
Hook scripts do not work in this way. They are non-interactive and
especially in the case of the pre-commit, will block others from
committing while the hook is executing.
There is no "dry run" for a commit. It's conceivable that you could
check the user ID in the pre-commit, and if the committer is JD,
reject the commit while mailing a diff to SD which represents the
change being attempted. This would require a lot of overhead on the
server though.
Honestly, I think you're trying to apply an excessively technical
solution to a fundamentally non-technical idea.
> Unfortunately, I still have a lot of doc to read about svn and not so much
> time as us all.
> But since I saw it working, I keep faith ;-)
>
>
>
> Le 17/02/2010 14:30, Andy Levy a écrit :
>>
>> On Wed, Feb 17, 2010 at 08:17, dcz<dc...@phpbb-seo.com> wrote:
>>
>>> Hello,
>>> Here is what I'm trying to do : some user (let's call them junior
>>> developer)
>>> should require their commit to be authorized by other (senior developer)
>>> before they would actually be committed.
>>>
>>> Since I saw this feature on an svn (though I do not administrate this
>>> one,
>>> so I can't tell how it is done, but it's svn for sure) and found it
>>> pretty
>>> useful, I was a bit surprised not to be able to find any topic about it
>>> after hours a googling.
>>>
>>> Would be very nice if someone could share thoughts about how to set such
>>> feature up.
>>>
>> Subversion has no such feature, which is why you can't find anything about
>> it.
>>
>> You can approach this a couple of ways. 2 that come to mind immediately:
>> 1) Junior developer (JD) submits patches to the senior developer (SD).
>> SD reviews the patch& commits when he's satisfied.
>> 2) JD gets his own private branch& can commit to it all day long.
>> When he's ready for a code review, SD looks it over& merges JD's work
>> into trunk (or wherever your main development is done). This will
>> require that JD's branch be kept up to date with regular merges from
>> trunk so that he's not conflicting with other peoples' work.
>>
>>
>>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Thanks for responding.
I was hopping that someone did put something together to handle this.
It looks like doable with a pre-commit hook that would have a look in a
db (or a file) to find out if the user is JD or SD. For JDs, the commit
could be made dry-run, and the script could in such case send a mail to
SDs who could later reply to in order to do the actual commit (eg
authorize it), or not.
Unfortunately, I still have a lot of doc to read about svn and not so
much time as us all.
But since I saw it working, I keep faith ;-)
Le 17/02/2010 14:30, Andy Levy a écrit :
> On Wed, Feb 17, 2010 at 08:17, dcz<dc...@phpbb-seo.com> wrote:
>
>> Hello,
>> Here is what I'm trying to do : some user (let's call them junior developer)
>> should require their commit to be authorized by other (senior developer)
>> before they would actually be committed.
>>
>> Since I saw this feature on an svn (though I do not administrate this one,
>> so I can't tell how it is done, but it's svn for sure) and found it pretty
>> useful, I was a bit surprised not to be able to find any topic about it
>> after hours a googling.
>>
>> Would be very nice if someone could share thoughts about how to set such
>> feature up.
>>
> Subversion has no such feature, which is why you can't find anything about it.
>
> You can approach this a couple of ways. 2 that come to mind immediately:
> 1) Junior developer (JD) submits patches to the senior developer (SD).
> SD reviews the patch& commits when he's satisfied.
> 2) JD gets his own private branch& can commit to it all day long.
> When he's ready for a code review, SD looks it over& merges JD's work
> into trunk (or wherever your main development is done). This will
> require that JD's branch be kept up to date with regular merges from
> trunk so that he's not conflicting with other peoples' work.
>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Thanks for responding.
I was hopping that someone did put something together to handle this.
It looks like doable with a pre-commit hook that would have a look in a
db (or a file) to find out if the user is JD or SD. For JDs, the commit
could be made dry-run, and the script could in such case send a mail to
SDs who could later reply to in order to do the actual commit (eg
authorize it), or not.
Unfortunately, I still have a lot of doc to read about svn and not so
much time as us all.
But since I saw it working, I keep faith ;-)
Le 17/02/2010 14:30, Andy Levy a écrit :
> On Wed, Feb 17, 2010 at 08:17, dcz<dc...@phpbb-seo.com> wrote:
>
>> Hello,
>> Here is what I'm trying to do : some user (let's call them junior developer)
>> should require their commit to be authorized by other (senior developer)
>> before they would actually be committed.
>>
>> Since I saw this feature on an svn (though I do not administrate this one,
>> so I can't tell how it is done, but it's svn for sure) and found it pretty
>> useful, I was a bit surprised not to be able to find any topic about it
>> after hours a googling.
>>
>> Would be very nice if someone could share thoughts about how to set such
>> feature up.
>>
> Subversion has no such feature, which is why you can't find anything about it.
>
> You can approach this a couple of ways. 2 that come to mind immediately:
> 1) Junior developer (JD) submits patches to the senior developer (SD).
> SD reviews the patch& commits when he's satisfied.
> 2) JD gets his own private branch& can commit to it all day long.
> When he's ready for a code review, SD looks it over& merges JD's work
> into trunk (or wherever your main development is done). This will
> require that JD's branch be kept up to date with regular merges from
> trunk so that he's not conflicting with other peoples' work.
>
>
>
Re: Junior developers
Posted by Andy Levy <an...@gmail.com>.
On Wed, Feb 17, 2010 at 08:17, dcz <dc...@phpbb-seo.com> wrote:
> Hello,
> Here is what I'm trying to do : some user (let's call them junior developer)
> should require their commit to be authorized by other (senior developer)
> before they would actually be committed.
>
> Since I saw this feature on an svn (though I do not administrate this one,
> so I can't tell how it is done, but it's svn for sure) and found it pretty
> useful, I was a bit surprised not to be able to find any topic about it
> after hours a googling.
>
> Would be very nice if someone could share thoughts about how to set such
> feature up.
Subversion has no such feature, which is why you can't find anything about it.
You can approach this a couple of ways. 2 that come to mind immediately:
1) Junior developer (JD) submits patches to the senior developer (SD).
SD reviews the patch & commits when he's satisfied.
2) JD gets his own private branch & can commit to it all day long.
When he's ready for a code review, SD looks it over & merges JD's work
into trunk (or wherever your main development is done). This will
require that JD's branch be kept up to date with regular merges from
trunk so that he's not conflicting with other peoples' work.
Re: Junior developers
Posted by Tucker <ju...@gmail.com>.
On Wed, Feb 24, 2010 at 3:10 AM, Alan Barrett <ap...@cequrux.com> wrote:
> On Wed, 17 Feb 2010, dcz wrote:
>> Here is what I'm trying to do : some user (let's call them junior
>> developer) should require their commit to be authorized by other
>> (senior developer) before they would actually be committed.
>
> You could require the junior developer to put a line like this
> in the log message:
>
> Approved by: <insert name of senior developer>
>
> Then you could have a pre-commit hook that rejects commits from junior
> developers, unless that line is present in the log message. If the
> junior developer lies about whether the code has been approved, then
> you have a non-technical problem to solve outside svn. You could also
> extend this by requiring the log message to contain a reference number
> to an external database that tracks code reviews and approvals.
>
> --apb (Alan Barrett)
>
I know this is old but I wanted to chime in (actually found this
thread while searching for references to Review Board).
While my use case is slightly different (we want approvals for all
commits, not just from a specific type of user), if you're capable of
doing some coding, this is a solvable problem. Here's the method I'm
working on:
Developer:
1) Checks out repository and makes changes.
2) When changes are ready for review, generate a changelist.
a) A changelist ID (integer) is generated in an SQL database.
b) The changelist ID is used to create a local SVN client
changelist, with that ID as the name.
c) A custom SVN revprop is set with the changelist ID.
3) User emails out the diff, to a reviewer, and a conversation commences.
Reviewer(s):
4) When the review has been approved (including any changes requesting
during the review), the reviewer marks the change as approved.
a) The changelist ID, in the database, has an is_approved boolean
and this is set True.
b) An e-mail is sent to the developer, informing them that their
change has been approved.
Developer:
5) Developer commits their changelist.
a) Pre-commit script checks the changelist ID revprop and verifies
that is_approved and active are both True. (active gets set false,
after a successful commit, so that changelist IDs don't get reused).
b) Post commit script grabs the commit revision and emails out a
commit notice, with revision information, to the reviewer(s) and sets
the active boolean, in our DB, to False.
While this is a somewhat complex procedure, it's really simple to
implement if you have some coding skills. Since my last employer was
a junkie for Python, I did all of this using pysvn
(http://pysvn.tigris.org/). I'd just give out the code (and may
still, if I can get permission to OSS it) but, for now, it's the
intellectual property of my current employer. I attempted a couple
other methods but this one worked the best, with the fewest race
conditions. The best part though is that it's an easy sell. This
method is based on what I recall of Google's code review methods, from
2004-2006 (implemented without having ever seen their actual code...
so it could definitely be better).
Beyond the normal SVN subcommands, I had implement these:
abandon
-If the change is decided to be bad, abandon it completely.
approve
-Allow a reviewer to simply run "custom_svn approve --cl <changelist_id>".
change
-Generate a changelist, and changelist config, based on current
workspace modifications.
client
-We want people to be able to manage repos independently, for various
reasons. This could be left out.
mail
-A developer only has to run "custom_svn mail --cl <changelist_id>" to
send out a request for review. I'm starting work on getting this to
talk to Review Board now (thus the search).
I also had to hijack and slightly reimplement commit, so that we can
run "custom_svn commit --cl <changelist_id>" and work my magic.
If you really only want to require review and approvals for junior
developers, that wouldn't be that hard to add. You could have a user
list and have the pre-commit script only trigger when a user is/isn't
in a list. If I were to do it, I would probably maintain LDAP groups,
based on language, for people who you trust to not need a review.
Again, using Google as a reference, having a group (like
python-trusted) that people are added to, once they past some sort of
coding/style test, and skipping the hard verification test would
probably be ideal.
Wow that was long... Again, I know this is a month old but I wanted
to toss my thoughts into the ring. If I am able to OSS this, or parts
of it, I'll make an announcement here and/or on the pvsvn list (after
I make sure it's not against the rules). If someone wants to chat
more about my implementation, I'm perfectly willing to talk non
specifics and help where I can.
--
--tucker
Re: Junior developers
Posted by Alan Barrett <ap...@cequrux.com>.
On Wed, 17 Feb 2010, dcz wrote:
> Here is what I'm trying to do : some user (let's call them junior
> developer) should require their commit to be authorized by other
> (senior developer) before they would actually be committed.
You could require the junior developer to put a line like this
in the log message:
Approved by: <insert name of senior developer>
Then you could have a pre-commit hook that rejects commits from junior
developers, unless that line is present in the log message. If the
junior developer lies about whether the code has been approved, then
you have a non-technical problem to solve outside svn. You could also
extend this by requiring the log message to contain a reference number
to an external database that tracks code reviews and approvals.
--apb (Alan Barrett)
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 22/02/2010 06:58, Srilakshmanan, Lakshman a écrit :
> Hi Dcz,
>
> One point of clarification. Each JD does ** not ** have their own branch.
> Each ** change ** has a branch. If the change is large and more than one developer is working on the change, they will all work in the same branch.
>
>
Hello Srilakshmanan,
But this means a JD branch separated from the SD one, if we do not want
to mess up too hard (the idea is to add many JD, starting with few SD so
... we need to make it simple for the SD)
Anyway, since redmine now has groups (we just updated), I'll use it to
handle JDs this way :
JD group can post private issues and attach a diff, SD review it and
authorise it (eg commit for real) and voila, eveythings is well traked
and simple enough this way.
Regards,
dcz
> Thanks
> Lakshman
> -----Original Message-----
> From: dcz [mailto:dcz@phpbb-seo.com]
> Sent: Thursday, 18 February 2010 7:43 PM
> To: users@subversion.apache.org
> Subject: Re: Junior developers
>
> Hello,
> Yes, could be a solution, use branches, but I would like to avoid the one branch per JD situation also. I'm currently investigating over review board if you have thoughts to share.
> FYI the trunk is indeed intended a stable stream.
>
> Le 17/02/2010 23:37, Srilakshmanan, Lakshman a écrit :
>
>> Hi dcz,
>>
>> You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
>> commit into trunk by only Senior Developers. This way the Junior
>> developer can perform his work in the branch and requests the Senior
>> Developer to review and merge his code back into trunk in preparation
>> for release. I am assuming you use trunk as a stable stream.
>>
>> Thanks
>> Lakshman
>> -----Original Message-----
>> From: dcz [mailto:dcz@phpbb-seo.com]
>> Sent: Thursday, 18 February 2010 12:17 AM
>> To: users@subversion.apache.org
>> Subject: Junior developers
>>
>> Hello,
>> Here is what I'm trying to do : some user (let's call them junior
>> developer) should require their commit to be authorized by other
>> (senior
>> developer) before they would actually be committed.
>>
>> Since I saw this feature on an svn (though I do not administrate this
>> one, so I can't tell how it is done, but it's svn for sure) and found
>> it pretty useful, I was a bit surprised not to be able to find any
>> topic about it after hours a googling.
>>
>> Would be very nice if someone could share thoughts about how to set
>> such feature up.
>>
>> Regards,
>>
>> dcz
>>
>>
>>
>>
>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Le 22/02/2010 06:58, Srilakshmanan, Lakshman a écrit :
> Hi Dcz,
>
> One point of clarification. Each JD does ** not ** have their own branch.
> Each ** change ** has a branch. If the change is large and more than one developer is working on the change, they will all work in the same branch.
>
>
Hello Srilakshmanan,
But this means a JD branch separated from the SD one, if we do not want
to mess up too hard (the idea is to add many JD, starting with few SD so
... we need to make it simple for the SD)
Anyway, since redmine now has groups (we just updated), I'll use it to
handle JDs this way :
JD group can post private issues and attach a diff, SD review it and
authorise it (eg commit for real) and voila, eveythings is well traked
and simple enough this way.
Regards,
dcz
> Thanks
> Lakshman
> -----Original Message-----
> From: dcz [mailto:dcz@phpbb-seo.com]
> Sent: Thursday, 18 February 2010 7:43 PM
> To: users@subversion.apache.org
> Subject: Re: Junior developers
>
> Hello,
> Yes, could be a solution, use branches, but I would like to avoid the one branch per JD situation also. I'm currently investigating over review board if you have thoughts to share.
> FYI the trunk is indeed intended a stable stream.
>
> Le 17/02/2010 23:37, Srilakshmanan, Lakshman a écrit :
>
>> Hi dcz,
>>
>> You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
>> commit into trunk by only Senior Developers. This way the Junior
>> developer can perform his work in the branch and requests the Senior
>> Developer to review and merge his code back into trunk in preparation
>> for release. I am assuming you use trunk as a stable stream.
>>
>> Thanks
>> Lakshman
>> -----Original Message-----
>> From: dcz [mailto:dcz@phpbb-seo.com]
>> Sent: Thursday, 18 February 2010 12:17 AM
>> To: users@subversion.apache.org
>> Subject: Junior developers
>>
>> Hello,
>> Here is what I'm trying to do : some user (let's call them junior
>> developer) should require their commit to be authorized by other
>> (senior
>> developer) before they would actually be committed.
>>
>> Since I saw this feature on an svn (though I do not administrate this
>> one, so I can't tell how it is done, but it's svn for sure) and found
>> it pretty useful, I was a bit surprised not to be able to find any
>> topic about it after hours a googling.
>>
>> Would be very nice if someone could share thoughts about how to set
>> such feature up.
>>
>> Regards,
>>
>> dcz
>>
>>
>>
>>
>
>
>
RE: Junior developers
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
Hi Dcz,
One point of clarification. Each JD does ** not ** have their own branch.
Each ** change ** has a branch. If the change is large and more than one developer is working on the change, they will all work in the same branch.
Thanks
Lakshman
-----Original Message-----
From: dcz [mailto:dcz@phpbb-seo.com]
Sent: Thursday, 18 February 2010 7:43 PM
To: users@subversion.apache.org
Subject: Re: Junior developers
Hello,
Yes, could be a solution, use branches, but I would like to avoid the one branch per JD situation also. I'm currently investigating over review board if you have thoughts to share.
FYI the trunk is indeed intended a stable stream.
Le 17/02/2010 23:37, Srilakshmanan, Lakshman a écrit :
> Hi dcz,
>
> You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
> commit into trunk by only Senior Developers. This way the Junior
> developer can perform his work in the branch and requests the Senior
> Developer to review and merge his code back into trunk in preparation
> for release. I am assuming you use trunk as a stable stream.
>
> Thanks
> Lakshman
> -----Original Message-----
> From: dcz [mailto:dcz@phpbb-seo.com]
> Sent: Thursday, 18 February 2010 12:17 AM
> To: users@subversion.apache.org
> Subject: Junior developers
>
> Hello,
> Here is what I'm trying to do : some user (let's call them junior
> developer) should require their commit to be authorized by other
> (senior
> developer) before they would actually be committed.
>
> Since I saw this feature on an svn (though I do not administrate this
> one, so I can't tell how it is done, but it's svn for sure) and found
> it pretty useful, I was a bit surprised not to be able to find any
> topic about it after hours a googling.
>
> Would be very nice if someone could share thoughts about how to set
> such feature up.
>
> Regards,
>
> dcz
>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Hello,
Yes, could be a solution, use branches, but I would like to avoid the
one branch per JD situation also. I'm currently investigating over
review board if you have thoughts to share.
FYI the trunk is indeed intended a stable stream.
Le 17/02/2010 23:37, Srilakshmanan, Lakshman a écrit :
> Hi dcz,
>
> You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
> commit into trunk by only Senior Developers. This way the Junior
> developer can perform his work in the branch and requests the Senior
> Developer to review and merge his code back into trunk in preparation
> for release. I am assuming you use trunk as a stable stream.
>
> Thanks
> Lakshman
> -----Original Message-----
> From: dcz [mailto:dcz@phpbb-seo.com]
> Sent: Thursday, 18 February 2010 12:17 AM
> To: users@subversion.apache.org
> Subject: Junior developers
>
> Hello,
> Here is what I'm trying to do : some user (let's call them junior
> developer) should require their commit to be authorized by other (senior
> developer) before they would actually be committed.
>
> Since I saw this feature on an svn (though I do not administrate this
> one, so I can't tell how it is done, but it's svn for sure) and found it
> pretty useful, I was a bit surprised not to be able to find any topic
> about it after hours a googling.
>
> Would be very nice if someone could share thoughts about how to set such
> feature up.
>
> Regards,
>
> dcz
>
>
>
Re: Junior developers
Posted by dcz <dc...@phpbb-seo.com>.
Hello,
Yes, could be a solution, use branches, but I would like to avoid the
one branch per JD situation also. I'm currently investigating over
review board if you have thoughts to share.
FYI the trunk is indeed intended a stable stream.
Le 17/02/2010 23:37, Srilakshmanan, Lakshman a écrit :
> Hi dcz,
>
> You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
> commit into trunk by only Senior Developers. This way the Junior
> developer can perform his work in the branch and requests the Senior
> Developer to review and merge his code back into trunk in preparation
> for release. I am assuming you use trunk as a stable stream.
>
> Thanks
> Lakshman
> -----Original Message-----
> From: dcz [mailto:dcz@phpbb-seo.com]
> Sent: Thursday, 18 February 2010 12:17 AM
> To: users@subversion.apache.org
> Subject: Junior developers
>
> Hello,
> Here is what I'm trying to do : some user (let's call them junior
> developer) should require their commit to be authorized by other (senior
> developer) before they would actually be committed.
>
> Since I saw this feature on an svn (though I do not administrate this
> one, so I can't tell how it is done, but it's svn for sure) and found it
> pretty useful, I was a bit surprised not to be able to find any topic
> about it after hours a googling.
>
> Would be very nice if someone could share thoughts about how to set such
> feature up.
>
> Regards,
>
> dcz
>
>
>
RE: Junior developers
Posted by "Srilakshmanan, Lakshman" <la...@police.vic.gov.au>.
Hi dcz,
You can write a pre-commit hook or use AuthzSVNAccessFile to restrict
commit into trunk by only Senior Developers. This way the Junior
developer can perform his work in the branch and requests the Senior
Developer to review and merge his code back into trunk in preparation
for release. I am assuming you use trunk as a stable stream.
Thanks
Lakshman
-----Original Message-----
From: dcz [mailto:dcz@phpbb-seo.com]
Sent: Thursday, 18 February 2010 12:17 AM
To: users@subversion.apache.org
Subject: Junior developers
Hello,
Here is what I'm trying to do : some user (let's call them junior
developer) should require their commit to be authorized by other (senior
developer) before they would actually be committed.
Since I saw this feature on an svn (though I do not administrate this
one, so I can't tell how it is done, but it's svn for sure) and found it
pretty useful, I was a bit surprised not to be able to find any topic
about it after hours a googling.
Would be very nice if someone could share thoughts about how to set such
feature up.
Regards,
dcz