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.

 

 

 

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

> >

Reply via email to