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 13:38:28 2006