[Commits etiquette]

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

while discussing with Alex, we agreed that the way we are committing
in trunk/bigbang is a little bit too permissive or loosy. Let me
explain :
- when we are fixing an issue, if we do more than one commit, then
it's difficult to track
- when we are fixing some code, from time to time, we are also fixing
some side problems (warning removal, refactoring, etc)
- the logs are not always enough to explain what has been changed

At this point, we need some more "rules" or etiquette to be applied.
Some of them could be :
- always commit a fix in one shot
- add the JIRA reference in the logs
- if you like to commit files one by one to add accurates comments,
just do it in a branch, and when done, merge the branch in one shot

Of course, these are just suggestions at this point, mainly pushed by
Alex, but we should also agreed on them as a team.

So I would ask you to tell us what is your opinion about those proposals.

wdyt? How can we improve the way we commit ?

Thanks a lot for any suggestion !

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [Commits etiquette]

[Alex Karasulu <ak...@apache.org>]

Thanks for pushing an email on this topic.

Alex

On Nov 26, 2007 4:40 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi guys,
>
> while discussing with Alex, we agreed that the way we are committing
> in trunk/bigbang is a little bit too permissive or loosy. Let me
> explain :
> - when we are fixing an issue, if we do more than one commit, then
> it's difficult to track
> - when we are fixing some code, from time to time, we are also fixing
> some side problems (warning removal, refactoring, etc)
> - the logs are not always enough to explain what has been changed
>
> At this point, we need some more "rules" or etiquette to be applied.
> Some of them could be :
> - always commit a fix in one shot
> - add the JIRA reference in the logs
> - if you like to commit files one by one to add accurates comments,
> just do it in a branch, and when done, merge the branch in one shot
>
> Of course, these are just suggestions at this point, mainly pushed by
> Alex, but we should also agreed on them as a team.
>
> So I would ask you to tell us what is your opinion about those proposals.
>
> wdyt? How can we improve the way we commit ?
>
> Thanks a lot for any suggestion !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Re: [Commits etiquette]

[Felix Knecht <fe...@apache.org>]

> 
> <TIP>
> A single revision can be used to commit changes across sub projects
> like shared and apacheds projects (or any other combinations with
> studio).  Just use the svn commit command with the paths of all the
> subprojects like so:
> 
>     svn commit /workingdirs/apacheds /some/path/shared/ldap
> /yet/another/path/studio
> </TIP>
> 
> 
>> When they are of most interest within the commit mails +1.
>> When they are of most interest later on when regarding at a svn history I'm not sure if it's really an easy way to go. I
>> don't know svn that deep but I'd estimate that after merging your branch to the trunk back again you won't have the
>> additional logs anymore (the ones you've created the branch for). So when wanting to see those extra log information you
>> need to checkout exactly this branch. As already said I'm not sure if this is the case, but if so -1.
> 
> <TIP>
> You can still query the logs of a branch even if the branch is not
> checked out of even if it no longer exists.  You can use svn log with
> the old position (URL) of the branch:
> 

Thanks for tips :-). I missed svn log up to now.I think it can be helping though add the branch url in the log when
merging the branch back (like the JIRA reference in the logs).

Thinking about CI. What about those reports maven can generate for us and which can be deployed either during nightly
build or for release build like
- http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html
- http://maven.apache.org/plugins/maven-changelog-plugin/changelog.html

It's just an idea.

Felix

Re: [Commits etiquette]

[Alex Karasulu <ak...@apache.org>]

Hi Felix,

On Nov 26, 2007 5:01 PM, Felix Knecht <fe...@apache.org> wrote:
> Emmanuel Lecharny schrieb:

...

> > - if you like to commit files one by one to add accurates comments,
> > just do it in a branch, and when done, merge the branch in one shot
> >
>
> I'm not sure about this. The question for me at this point is "Where are the log entries of interest?".

Please keep in mind that this suggestion was intended for cases when
each file changed is being committed one at a time often with the same
log message.  I'd rather have one commit that ties the picture
together with that log message.

However, even if the log message is not the same, it makes sense
sometimes to summarize or group all these changes together into a
single commit after a merge for a coherent unit of work.  It sure does
make searching the logs and getting a clear idea of the logical fix
much much easier.

<TIP>
A single revision can be used to commit changes across sub projects
like shared and apacheds projects (or any other combinations with
studio).  Just use the svn commit command with the paths of all the
subprojects like so:

    svn commit /workingdirs/apacheds /some/path/shared/ldap
/yet/another/path/studio
</TIP>


> When they are of most interest within the commit mails +1.
> When they are of most interest later on when regarding at a svn history I'm not sure if it's really an easy way to go. I
> don't know svn that deep but I'd estimate that after merging your branch to the trunk back again you won't have the
> additional logs anymore (the ones you've created the branch for). So when wanting to see those extra log information you
> need to checkout exactly this branch. As already said I'm not sure if this is the case, but if so -1.

<TIP>
You can still query the logs of a branch even if the branch is not
checked out of even if it no longer exists.  You can use svn log with
the old position (URL) of the branch:

svn log https://svn.apache.org/repos/asf/directory/apacheds/branches/existing_branch

-OR-

svn log -r rev_before_deletion
https://svn.apache.org/repos/asf/directory/apacheds/branches/deleted_branch

-OR-

svn log --revision (2007-11-23)
https://svn.apache.org/repos/asf/directory/apacheds/branches/deleted_branch

</TIP>

Alex

Re: [Commits etiquette]

[Felix Knecht <fe...@apache.org>]

Emmanuel Lecharny schrieb:
> Hi guys,
> 
> while discussing with Alex, we agreed that the way we are committing
> in trunk/bigbang is a little bit too permissive or loosy. Let me
> explain :
> - when we are fixing an issue, if we do more than one commit, then
> it's difficult to track

Definitely +1!

> - when we are fixing some code, from time to time, we are also fixing
> some side problems (warning removal, refactoring, etc)
> - the logs are not always enough to explain what has been changed
> 
> At this point, we need some more "rules" or etiquette to be applied.
> Some of them could be :
> - always commit a fix in one shot

+1

> - add the JIRA reference in the logs

+1. I think that in this case JIRA is also able to find and link the commits in the issue.

> - if you like to commit files one by one to add accurates comments,
> just do it in a branch, and when done, merge the branch in one shot
> 

I'm not sure about this. The question for me at this point is "Where are the log entries of interest?".
When they are of most interest within the commit mails +1.
When they are of most interest later on when regarding at a svn history I'm not sure if it's really an easy way to go. I
don't know svn that deep but I'd estimate that after merging your branch to the trunk back again you won't have the
additional logs anymore (the ones you've created the branch for). So when wanting to see those extra log information you
need to checkout exactly this branch. As already said I'm not sure if this is the case, but if so -1.

My thoughts
Felix