I have a svn repository where files are checked in in this format.
<filename>.<ext>-rev<revision number>
There is another file where the revision number is entered. When build is done, then this file is parsed and the file with corresponding rev number is taken and renamed to a standard file name . and final build is done.
How to get the changelist number of svn before you are submitting?
You might try doing an svn up and getting last revision and use that rev+1. But as Mark Dickinson said, if someone else updates there will be issues.
I would try a different approach.
There is no safe way of obtaining the revision number before performing the commit. This would require clients to be able to lock the repository.
Why do you want a new file checked in for each new revision? I'm sure there is a better solution to the problem you're trying to solve.
I think I have the whole picture now.
The scenario is like this. Some code is checked out from a different branch of repository.Fixes are made and the resulting changes are submitted into that repository.(a revision number is obtained on check-in)
A binary(lib) is created with these changes.This lib is part of a bigger module and this binary is checked into this module as - and the make file is modified to pickup this binary-revno and rename it as and use this in creating the bigger module.
I think you're misusing the version control system. You shouldn't need to put revision numbers or dates into file names when you're using a VCS. The VCS will store that information for you automatically, as metadata. Instead of checking in a new file every time with a new revision/date, you should replace the old file. The old files will always be availble in the VCS history if you need them for some reason. In addition to reducing clutter, this has the advantage of always keeping the same file name which makes automation easier.
Also, as a general rule, you don't want to commit compiled binaries to the source tree. You should only commit the files you need to build the binaries (namely, the source and the makefile).
If you really do want to continue on your current plan, you're going to have difficulty. There's no way to know what revision number you will get until after the commit succeeds -- this is a basic design guarantee of the atomic commit concept. The best you can do is add a post-commit hook that checks out a copy of whatever was just committed and renames the file to be the revision number. This means the name change of the file will reflect an earlier revision than the one where the name change takes place, but it will allow you to have the file name revision number be the same as the changes that you made, which I think is what you want. This technique will also result in 2 commits for every change. I don't recommend it.
Look at "SvnRev" which is currently available here: http://www.compuphase.com/svnrev.htm
It sound like you are trying to implement some sort of CHANGELOG or a release tagging system where users can select different released versions. So, assuming that is what you were looking for here is what I did in a similar situation. I realize your question is a year old, but maybe someone else will find this.
What I did was maintain separate file to store the history of revisions of special interest. I have a projects where I make an "official" installer for our entire application. Normally I wouldn't store generated code in a version control system, but these binaries we treat as special. We like to keep the exact binary that we deliver to a user. We don't want to rebuild them later and storing them in SVN is a convenient abuse of version control... So what I do is build my installer binary; commit the installer binary to SVN; get the SVN Revision of the installer that I just committed; append Revision/date/notes to a file called CHANGELOG; and finally I commit the CHANGELOG file. The Revision number of the CHANGELOG will be one or more than the installer, but I only care about the Installer's Revision numbers. For extra convenience the installer is copied to a web server and placed under a directory named with the installer's Revision number. But we can always look at the CHANGELOG notes to find the revision of an installer that we want and check it out by that Revision. We can also use that Revision number to checkout the source used to build the installer (you must be sure nobody committed changes between your source checkout/build and the installer commit). If you really don't mind wasting disk space you can do a tag; build; and commit the installer back to the tag. Svn doesn't really have tags, of course, so you would do an "svn copy"; but then a real tagging system wouldn't let you commit changes back to it. -- Noah