You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2006/08/26 22:39:30 UTC

Patch all or individual commits?

I hope everyone doesn't mind putting up with my newbie committer 
questions. They will hopefully come to the end soon :-)

I committed one file and that turned out fine. So now my question is: 
when you have X files you want to check-in, do we have any policy here 
on the expected way of doing it? Do we create a patch for the whole darn 
thing and apply the patch? Or do we just individually check-in files?

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: [OT] Re: Patch all or individual commits?

Posted by Paul Speed <ps...@progeeks.com>.

Antonio Petrelli wrote:

> Ted Husted ha scritto:
> 
>> Something that could go wrong under CVS is that one file's commit
>> would fail, the others would succeed, and the repository would be in
>> an unexpected state.
> 
> 
> Thank you, I didn't know this CVS problem (maybe because I am too much 
> lucky :-) )
> Now I understand why so much people is migrating from CVS to SVN.
> 
> Ciao
> Antonio

Well, and it may only be accepted (but partially incorrect) lore at this 
point.  It all depends on why the commit fails.  If it fails for any 
normal reason then CVS should do the right thing.  At my day job we have 
validation scripts for commits that can reject a file and we routinely 
do commits across multiple directories, etc..  We've never had an 
inconsistent commit from this.

But the lore came from somewhere so your mileage may vary I guess.
-Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: [OT] Re: Patch all or individual commits?

Posted by Antonio Petrelli <br...@tariffenet.it>.
Ted Husted ha scritto:
> Something that could go wrong under CVS is that one file's commit
> would fail, the others would succeed, and the repository would be in
> an unexpected state.

Thank you, I didn't know this CVS problem (maybe because I am too much 
lucky :-) )
Now I understand why so much people is migrating from CVS to SVN.

Ciao
Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: [OT] Re: Patch all or individual commits?

Posted by Ted Husted <hu...@apache.org>.
On 8/28/06, Antonio Petrelli <br...@tariffenet.it> wrote:
> Where is The Truth? :-P

In the implementation. :)

Something that could go wrong under CVS is that one file's commit
would fail, the others would succeed, and the repository would be in
an unexpected state. Smaller commits could be better, since it meant
there was less that could go wrong. SVN uses atomic committs, so
larger, multifile commits are not risky. It all succeeds, or it all
fails.

Under SVN, it's easy to roll things back to a particular commit, and
to reference the changes by the revision number. So if we are
implementing change XYZ, it's helpful to be able to say the change was
implemented in r1234567. And if we decde to roll back, we have an
implicit tag corresponding to the change.

Under CVS, I don't think I ever actually "rolled back" a commit. It
was too much work. Of I needed to undo something, I copy-and-pasted
the code forward. Under SVN, I often rolled back commits that didn't
work, by using SVN to copy forward the files that I want. (Not so much
here, but at work.)

Though, in either case, if the changes to the files are coupled, and
we aren't talking about a humungous number of CVS files, I'd commit
the changes together, for the same reason: "so it is clear what it is
changed in that file and why it has been done."

The evil practice is committing unrelated changes together, or mixing
stylistic and functional changes in the same commit.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


[OT] Re: Patch all or individual commits?

Posted by Antonio Petrelli <br...@tariffenet.it>.
Martin Cooper ha scritto:
> Please try to check in all of the files for a particular issue in a 
> single
> commit.

Funny how things changed since the use of CVS. I don't remember where I 
read it, but someone wrote that it is better to commit a single file at 
a time, so it is clear what it is changed in that file and why it has 
been done. Notice that I agree with both Martin and Wendy :-)
As I see it, things in IT go back and forth, for instance the recent 
re-consideration of Model 1 webapp structure, lovers and haters of XML, 
to strong-type or not-to-strong-type, etc.
Where is The Truth? :-P

Ciao
Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Patch all or individual commits?

Posted by Martin Cooper <ma...@apache.org>.
On 8/26/06, Paul Benedict <pb...@apache.org> wrote:
>
> I hope everyone doesn't mind putting up with my newbie committer
> questions. They will hopefully come to the end soon :-)
>
> I committed one file and that turned out fine. So now my question is:
> when you have X files you want to check-in, do we have any policy here
> on the expected way of doing it? Do we create a patch for the whole darn
> thing and apply the patch? Or do we just individually check-in files?


Please try to check in all of the files for a particular issue in a single
commit. That way, it's easy to point to all of the changes, since they're
marked with a single SVN revision number, and it's also easy to back out the
change, if that ever becomes necessary, for the same reason. Checking in the
files individually really defeats the advantages of our source control
system.

--
Martin Cooper


Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Patch all or individual commits?

Posted by James Mitchell <jm...@apache.org>.
Not sure if you wanted this level of detail, but just in case you are  
wondering how to commit multiple files, or across multiple sections  
of the file system, you can specify any number of folders and  
anything that needs committing under it will be added.

So, for example (using a command line svn client):

+-foo/
   +-bar/
   +-baz/


Given the above directory, too see changes under foo/
  $ cd foo/
  $ svn status

The result may show (for a better explanation type "$ svn help status"):
  X - for any directories that are brought in via svn:externals  
(please let me know if you don't know what that is, I can explain  
further)
  ? - for any files that are not under svn, and not being ignored via  
svn:ignore
  M - for any files that you've modified
  A - for any files that you have either added with "svn add" or  
moved with "svn mv"
  D - for any files that you have removed with either "svn rm" or  
moved with "svn mv"
  C - for any conflicts, where you may have made a modification, then  
updated ("svn up") and someone else made a modification that has  
conflicts with your local version (same concept in cvs)

Now that the status of the files are listed, you can see the actual  
differences with "svn diff".  I usually pipe it to the "less" command  
so that I can page back and forth to review my pending changes.

  $ svn diff | less


So, let's say that in reviewing you're local changes, you've got 5  
modified files in foo/bar, but you only want to commit 3 of them, and  
you have changes under foo/baz/ and you want them *all* of it to be  
committed:

  $ svn commit -m "fixing some code" foo/bar/file1.txt foo/bar/ 
file2.txt foo/bar/file3.txt foo/baz/

If you create a system property for SVN_EDITOR, you can omit the  
commit message (-m "") and you'll be prompted with the editor you  
specify.

I use SVN_EDITOR=vi

HTH


--
James Mitchell
678.910.8017




On Aug 27, 2006, at 12:59 AM, Paul Benedict wrote:

> Wendy Smoak wrote:
>> Also, remember to refer to the issue number in the commit message so
>> it will automatically show up on the 'Subversion Commits' tab in JIRA
>
> Do you have an example commit message? If there's a special format,  
> please let me know.
>
> PS: When this is all done, I should probably collect all these tips  
> and add them to our home page. Unless I missed all these guidelines  
> (it is quite possible!), it's worth documenting.
>
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Patch all or individual commits?

Posted by Wendy Smoak <ws...@gmail.com>.
On 8/26/06, Paul Benedict <pb...@apache.org> wrote:

> Wendy Smoak wrote:
> > Also, remember to refer to the issue number in the commit message so
> > it will automatically show up on the 'Subversion Commits' tab in JIRA
>
> Do you have an example commit message? If there's a special format,
> please let me know.

Any of the recent commits, but you're probably already getting them:
   http://mail-archives.apache.org/mod_mbox/struts-commits/

We don't have a template.  As long as you mention the issue number
somewhere in the commit message, JIRA will find it.  Some people lead
off the commit message with it, some put it on a separate line below,
some just mention it in a sentence.

If you're applying someone else's patch, put 'Submitted By: ...' on a
separate line.

> PS: When this is all done, I should probably collect all these tips and
> add them to our home page. Unless I missed all these guidelines (it is
> quite possible!), it's worth documenting.

It's probably not documented, just things we've discussed on dev@.
This page might work:
http://wiki.apache.org/struts/StrutsMaintenanceSvn

HTH,
-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Patch all or individual commits?

Posted by Ted Husted <hu...@apache.org>.
On 8/27/06, Paul Benedict <pb...@apache.org> wrote:
> Do you have an example commit message? If there's a special format,
> please let me know.

The thing to keep in mind is that alot of the team communication
happens through the commits and the commit logs. (And *all* of the
team communication goes over the dev, commits, or issues lists.)

People are watching the commits, and they are trying to follow what
changes are being made. The reason we group the commits around issues
is that it's easier for other people to follow the changes, both now
and years from now.

Put into the commit message anything that will make it easier for
people to follow what is happening. (Where people include yourself six
months or six years from now.)

Remember that the commit messages not only go out by email, and stored
in the repository, but they are available online as well.

* http://svn.apache.org/viewvc/struts/struts1/trunk/core/src/main/java/org/apache/struts/config/ActionConfig.java?view=log

When reports come in on code that we haven't worked on, most of us
will review the commit messages, to see if the issue has been
addressed before.

Short one-line messages are fine, if they provide all the information
that an observer would need to understand the commit. I've also seen
two-thousand word messages for commits that included a lot of
functionality.


> PS: When this is all done, I should probably collect all these tips and
> add them to our home page. Unless I missed all these guidelines (it is
> quite possible!), it's worth documenting.

We conduct all of the development work and team communications on the
public lists, so to a degree, we expect people to learn to be
committers by watching other committers.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Patch all or individual commits?

Posted by Paul Benedict <pb...@apache.org>.
Wendy Smoak wrote:
> Also, remember to refer to the issue number in the commit message so
> it will automatically show up on the 'Subversion Commits' tab in JIRA

Do you have an example commit message? If there's a special format, 
please let me know.

PS: When this is all done, I should probably collect all these tips and 
add them to our home page. Unless I missed all these guidelines (it is 
quite possible!), it's worth documenting.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Patch all or individual commits?

Posted by Wendy Smoak <ws...@gmail.com>.
On 8/26/06, Paul Benedict <pb...@apache.org> wrote:

> I hope everyone doesn't mind putting up with my newbie committer
> questions. They will hopefully come to the end soon :-)
>
> I committed one file and that turned out fine. So now my question is:
> when you have X files you want to check-in, do we have any policy here
> on the expected way of doing it? Do we create a patch for the whole darn
> thing and apply the patch? Or do we just individually check-in files?

As much as possible, commit everything related to a particular issue at once.

Also, remember to refer to the issue number in the commit message so
it will automatically show up on the 'Subversion Commits' tab in JIRA,
and provide enough information so that someone looking at _only_ the
svn logs can figure out what happened.  JIRA is great, but the commit
logs will probably outlive it.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org