;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
Your best bet is obviously to win the good fight and convince everyone
that the mechanism was changed for a reason. The key is to explain
that the revision number is pretty much useless and only the tag is
important. Each release should be tagged or in the case of the head
line of code, be referred to by its intrinsic revision number "HEAD".
All change management, defects, ... etc. are driven from the tag name.
Hacking atomic revision numbers into SVN will be problematic at best.
Perhaps you could show that under CVS, one has no idea as to what the
revision number of any particular file is in a given release and that
the is extra effort required to identify. Under SVN however once you
resolve the tag name to a revision number, you know now the revision
number of every file in the release. Still that information is
ultimately useless because " the tag is the only thing that matters".
again ...
http://subversion.tigris.org/faq.html#globalrev
Either way the svnprops tool probably won't do the trick because firs
you would have to automate it and second the coordination required to
control atomic revision numbers from the client side would be futile.
You would need to find a way to hook in from the server side and keep
in mind that you can't use the server side hooks as any properties you
set will not make it back to the client side unless they update.
However if these imposed atomic revision numbers are only relevant to
management and the rest the enlightened users will be practically
ignoring them any way this might be an acceptable hack ;)
As for svnprops, I designed that to deal with infected modules. See we
started using SVN before all the clients auto props were configured.
So even after I got all the clients configured, I still needed a way
to traverse and set all the appropriate properties in order to clean
up. But is is still very useful any time you need to set properties
and a selection of files. It's cool because you can identify the file
set with a regex.
Buy the way we use TortoiseSVN too. Here (attached) is a registry file
that will turn credential caching on and configure a decent set of
autoprops. We have remotely pushed it to all our users. For more
information and specifics see:
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-1.2
And the warning about setting properties in via hooks on the server
side is at (scroll down a bit to run into it ...):
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-5-sect-2.1
- Dan
On 2/1/06, Ryan Schmidt <subversion-2006Q1@ryandesign.com> wrote:
> On Feb 1, 2006, at 11:47, Alfredo Chinchilla wrote:
>
> > I think your script could really help us in our project, my
> > management is about to get rid of Subversion because we are unable
> > to have a sequential automatic "version" number at the file level
> > ... I have try hard to explain the concept of revisions at the
> > project level, but they insist to have as well a sequential number
> > at the file level linked to the history of each file. My project is
> > an Oracle Applications ERP implementation. I'm using subversion
> > 1.2.3 installed on AIX 2.3 and TortoiseSVN client to check in and
> > out code from the repository. If we were able to use your script to
> > define a custom property called "version" that can be increased
> > automatically every time you commit a modification of a file, that
> > will be great!!
>
> Your management sounds like a bunch of pointy-haired lunatics, and
> I'd try to get them to understand this concept:
>
> http://subversion.tigris.org/faq.html#globalrev
>
> Revisions are of course not at the project level, but at the
> repository level, and the number has no meaning besides "the number
> of changes that have taken place in this repository." If you have
> elected to place each project in its own repository, then
> coincidentally for you the revisions are at a project level, but that
> doesn't make them any more meaningful.
>
> The arguments in the FAQ against assigning meaning to a repository-
> wide revision are just as true about your hypothetical file-bound
> "version." If you had a "version" property, why would you care *how
> many* changes had taken place? If I add and delete a blank line 50
> times, the "version" increases by 100, but nothing of substance has
> been done to the file. Wouldn't you be much more interested in *what*
> changes had been made, and why? The log and diff subcommands answer
> these questions very well.
>
>
> >> http://groups.google.com/group/Subversion-SVN/browse_thread/thread/
> >> d43b2deb8c79e3ea/56f81823623c4417#56f81823623c4417
>
> Read the comment on that page again. It says "Why the hell do I need
> this? Because SVN has no repository side mechanism which compliments
> client side auto-props! You may be thinking about using the hook
> scripts but, note the WARNING in the svn documentation!" That means
> this script is intended to be used from the client side, not the
> server side.
>
> I don't find the exact page in the documentation where the warning
> appears, but it most likely explains why you do not want to try to
> change the transaction in the pre-commit hook. The reason is that the
> user's working copy will think it is up-to-date when in fact it is
> not (because you have changed it on the server side). With properties
> this is possibly less tragic than if it were the file contents, but
> it still smells like a bad idea.
>
> What would you do with a custom "version" property if you had one?
> Given the fact that the hooks cannot communicate anything other than
> error messages back to the client, if I check out a working copy
> where a file has "version" 2, and then I make changes and commit,
> twice, then in the repository the "version" of the file will have
> been updated to 4, but on the client, it will still be 2, since
> Subversion has no mechanism by which it could inform the client of
> the change. So the only way to accurately read the property would be
> to look in the repository directly, or on a freshly-checked-out
> working copy. (Simply updating an existing working copy cannot be
> guaranteed to work, as I said, because the working copy would already
> think it was up to date, even though it is not.)
>
> So perhaps by jumping through some hoops you can determine what the
> "version" of a file *is*. How will you determine what its "version"
> *was* at any point in the past? Subversion provides no mechanism to
> search for arbitrary properties, so you would have to use a
> repository-wide revision to back-date a working copy to a previous
> revision anyway, just to be able to read the custom property value to
> see what it was. Or you could set up a separate database (MySQL,
> whatever) and a post-commit hook script which would transcribe your
> custom properties into the database such that you could search them
> using the database's search facilities. But I hope you see that this
> is all becoming an immense amount of effort and silliness for a
> benefit which I haven't yet understood.
>
>
> > Any ideas on how to use your script to achive what we need, or
> > any
> > other ideas that can help us to satisfy our Management demands will
> > be much appreciated.
>
> If you can get your management to explain what exactly they are
> trying to achive with this, and explain it to us, then maybe we can
> tell you the more Subversionesque way to do the same thing.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 1 16:43:47 2006