Mark Combellack wrote:
Hi,
The main reasons that I like the SVN details in the header of the files
include:
* You can look at the source file and see what revision it is
without having to use SVN commands
* Typically, developers will do an SVN checkout of the code using
SVN so they can get the information via SVN commands or via the headers
* Typically, users do not do an SVN checkout of the source code and
will not have SVN installed. They are typically provided with a jar file
containing the source code. They will not be able to run SVN command to work
out which versions of source code they are running
* Typically, there are many, many more users than there are
developers
* If a source file is printed out or attached as an email as part of
a bug report or published on a web server, the source code will contain the
SVN revision number. This makes the bug easier to fix as you know the
revision number. The SVN commands will not be able to tell you the revision
number in these scenarios.
The nice thing about the SVN keyword substitution is that a Developer is
free to choose whether they want them or not as the expansion is done on the
client side. If a Developer wants the $Date$ and $Revision$ expanded, then
they have to update their SVN configuration to do so. If they do not, then
they don't need to do anything as it is disabled in SVN by default. The key
thing is that @version $Date$ $Revision$ is in the header to provide this
choice.
Thanks for this explanation, and for bringing in the user perspective.
I can see that having expanded version information may be useful in
this user context. It is not very useful to me as a developer, and
it can hurt me with applying patches if I enable the keyword expansion,
but I can turn this expansion off in my SVN client to suit my preference.
Taking all of this into account, I am +1 on this change.
Regarding whether or not we have consensus and whether we should hold
a vote, consensus is not the same as unanimity. I think we need to
make a decision on this issue (which is relatively minor) and move
forward. Holding a vote seems to be a reasonable way to do this.
Simon
At the end of the day, from my personal opinion, using @version $Date$
$Revision$ is a nice to have feature in the source code. I would like to
have it there. However, I would rather go without it if its presence is
going to cause disharmony amongst the Tuscany Developers.
Thanks,
Mark
-----Original Message-----
From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED]
Sent: 24 April 2008 08:04
To: [email protected]; [EMAIL PROTECTED]
Subject: Re: Adding SVN version to Java files
I would like to know the last revision and date at which a particular file
is updated just by opening the file in any editor and without having to do
anything extra, for e.g., like installing a plugin for eclipse, opening a
command prompt to issue an svn info command (note that the source I have
need not always be from svn, it could be a source archive for a release
downloaded separately), etc. I found this info very useful while
investigating JIRAs.
++Vamsi
On Thu, Apr 24, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy
<[EMAIL PROTECTED]>
wrote:
<snip>
From the above, we have 4 +1s and no -1s - although we have a
preference not
to do this from ant. So, the consensus is to make this change.
We haven't held a formal vote, so I don't think we should be
trying
to decide this based on a count of +1s and -1s.
Agreed. We should hold a formal vote.
We do consensus based development. Voting can be a useful gauging
consensus
but voting does not make consensus. Its obvious from this thread that
there
is not (yet) consensus so we don't need a vote, how about instead trying
to
convince us by explaining the value of adding this?
...ant
