Yes it does. Under the issue you can find a tab Subversion Commits. Scott
> -----Original Message----- > From: Michael Herndon [mailto:mhern...@wickedsoftware.net] > Sent: Monday, March 14, 2011 2:38 PM > To: lucene-net-...@lucene.apache.org > Cc: Digy > Subject: Re: [Lucene.Net] Procedure for Commiting > > Is Jira not currently setup to track the commit messages with the > referenced > ticket number in them? > > On Mon, Mar 14, 2011 at 12:59 PM, Digy <digyd...@gmail.com> wrote: > > > I don't know what others think, but I find it more trackable to see the > > issues and related patches in one place(JIRA) > > (especially, while trying to understand what was done for a specific > issue; > > after many months) > > > > DIGY > > > > > > -----Original Message----- > > From: Stefan Bodewig [mailto:bode...@apache.org] > > Sent: Monday, March 14, 2011 5:41 PM > > To: lucene-net-...@lucene.apache.org > > Subject: Re: [Lucene.Net] Procedure for Commiting > > > > On 2011-03-14, Scott Lombard wrote: > > > > > I wanted to get a final agreement on how we want to handle commits to > the > > > repository. There have been discussions in a couple of different > threads > > > about this topic. I know patches, branches and just go for it has > been > > > discussed and different people have different ideas. I just wanted to > > know > > > what the group thinks is the way to handle commits in our project. > > > > Inside the ASF we have varying ideas about how to handle it. > > > > Many if not most projects use commit-then-review (CTR[1]) as their main > > model where you just commit and your peers review it later (that's why > > the commits mailing list exists). This is probably the quickest way to > > move forward but may lead to slipped-through problems. > > > > At the other extreme there are projects that require JIRA items for each > > and every commit with automated pre-build CI checks that reject patches > > attached to JIRA tickets if they break the > > build/tests/coding-standards/whatever[2]. This is probably the "safe" > > way but may keep people from contributing because the effort to get a > > patch in seems to big. > > > > Other projects live in some sort of middle ground where some branch is > > open for CTR and other branches (the "stable" branch) requires > > review-then-commit (RTC[3]). Many projects have written down policies > > like Hadoop which I've already cited or Solr[4]. > > > > I guess what I'm trying to say is there is no policy that would force > > you to do it one way or the other, it is your decision. > > > > Stefan > > > > [1] http://www.apache.org/foundation/glossary.html#CommitThenReview > > > > [2] http://wiki.apache.org/hadoop/HowToContribute > > > > [3] http://www.apache.org/foundation/glossary.html#ReviewThenCommit > > > > [4] http://wiki.apache.org/solr/CommitPolicy > > > > This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
