"svn info <filename>" command will display information as given in the example output below:
------------------------------------------ Path: pom.xml Name: pom.xml URL: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-em bedded/pom.xml Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 643735 Node Kind: file Schedule: normal Last Changed Author: lresende Last Changed Rev: 639026 Last Changed Date: 2008-03-20 03:05:13 +0530 (Thu, 20 Mar 2008) Text Last Updated: 2008-03-20 12:47:48 +0530 (Thu, 20 Mar 2008) Checksum: bd9c1e3dd4c14558e23de334db5da999 ---------------------------------------- I use TortoiseSVN on WindowsXP. With this, when the file properties dialog is launched by right-clicking on the file and selecting "properties", there is a "Subversion" tab that shows some of the information given in the example above. ++Vamsi On Wed, Apr 2, 2008 at 8:25 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > Vamsavardhana Reddy wrote: > > > The one use I see is that by looking at the file (and not doing anything > > extra), I can quickly learn the last revision at which it is modified. > > Otherwise, I will have to look at the file properties or svn log to know > > that revision number. I find that it saves time while investigating > > issues. > > > > This is what I would like to be able to do. How do I look at the > file properties to find out this information? Is there an svn command > or commands to do this? > > Simon > > > ++Vamsi > > > > On Wed, Apr 2, 2008 at 3:07 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > > On Mon, Mar 31, 2008 at 8:01 PM, Jean-Sebastien Delfino < > > > [EMAIL PROTECTED]> wrote: > > > > > > ant elder wrote: > > > > > > > > On Mon, Mar 31, 2008 at 7:27 PM, Jean-Sebastien Delfino < > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > Mark Combellack wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I've been looking through the Tuscany source code and noticed > > > > > > > that > > > > > > > some > > > > > > > files have a @version containing the SVN revision number in > > > > > > > their > > > > > > > > > > > > > > JavaDoc > > > > > > > > > > > > headers but others do not. > > > > > > > > > > > > > > As an example, @version might look like: > > > > > > > > > > > > > > /** > > > > > > > * Some JavaDoc for the class > > > > > > > * > > > > > > > * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 +0000 > > > > > > > (Sun, > > > > > > > > > > > > > 25 > > > > > > > Nov > > > > > > > 2007) $ > > > > > > > */ > > > > > > > > > > > > > > I would like to go through the Tuscany source code and add > > > > > > > this > > > > > > > header > > > > > > > > > > > > > > where > > > > > > > > > > > > it is missing. This would involve a large number of minor > > > > > > > changes > > > > > > > > > > > > > to > > > > > > > the > > > > > > > Tuscany tree so I wanted to run it by everyone to make sure > > > > > > > no-one > > > > > > > had a > > > > > > > problem with me doing this at this time. > > > > > > > > > > > > > > I'll probably start this next week unless there is an > > > > > > > objection. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Mark > > > > > > > > > > > > > > We're next week now :) > > > > > > > > > > > > > Here's a summary of what I've seen in that thread so far: > > > > > > - Mark would like to help add SVN revision headers to all files > > > > > > - Vamsi +0.5 and suggests to set up to add headers to new files > > > > > > - Luciano +1 and agrees to set up SVN and IDE for this > > > > > > - Ant prefers not to this, not useful and clutters up the code > > > > > > - Sebastien +1 and also suggests to set up our IDEs for this > > > > > > - Simon would it find useful and also happy to set up his IDE > > > > > > > > > > > > 5 people seem to be reaching consensus, 1 prefers not to do it. > > > > > > > > > > > > Ant, do you still have any objections against doing this? > > > > > > > > > > > > > > > > > > Yep, I don't think we should do it. > > > > > > > > > > > No one has given any even vaguely compelling reasons for using > > > > > them > > > > > > > > > but > > > > > > > for > > > > > them to have the very occasional usefulness _everyone_ has to > > > > > always > > > > > have it > > > > > set up which will inevitably go wrong occasionally for someone > > > > > which > > > > > makes > > > > > them completely unreliable anyway - how do you know that src > > > > > you're > > > > > looking > > > > > at isn't one of the files which has been corrupted by someone with > > > > > a > > > > > > > > > bad > > > > > > > environment? And it adds just another cause of negative emails to > > > > > the > > > > > > > > > ML > > > > > > > when complaining that someone has done it wrong. All that is exactly > > > > > what > > > > > used to happen in the bad old days when we did use them. > > > > > > > > > > Doesn't using svn info work as a replacement in a lot of > > > > > circumstances > > > > > anyway? And if not then what are the circumstances where you're > > > > > having > > > > > to > > > > > look at src out of version control or out of a released distro? > > > > > This > > > > > _is_ > > > > > open source so its normal to have access to the version control > > > > > system > > > > > not > > > > > like in closed src dev when its more likely there'll be > > > > > uncontrolled > > > > > > > > > src > > > > > > > floating around. > > > > > > > > > > And its yet another burden to place on Tuscany development, i just > > > > > > > > > don't > > > > > > > understand the feeling that somehow things would be better if we had > > > > > more > > > > > formal processes and procedures in place - not having many of > > > > > those it > > > > > what > > > > > I like about developing at Apache. > > > > > > > > > > ...ant > > > > > > > > > > > > > > > Are you saying that we should remove them? What if I want to add > > > > them to > > > > the new files I'm editing (which is what I'm doing at the moment). > > > > Are > > > > > > > you > > > > > > > going to object to these commits? > > > > > > > > > > > > -- > > > > Jean-Sebastien > > > > > > > > I'd like to understand why we need them. If there are some real > > > cases of > > > where they really are useful then maybe it is worthwhile but right now > > > no > > > one has suggested any? > > > > > > ...ant > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
