Jamax wrote:
> I'm sorry you guys feel that asking for an improvement to the software is
> trolling. And I have leveled no insults at any person here. When my tone
> has been negative, maybe it has something to do with people regularly asking
> for this feature for 5+ years and it seemingly being fairly trivial for
> somebody already into the source to implement.
I apologize for my hasty remark earlier; it was not fair to you or to the list.
Just because I perceived your comments to be arrogant and dismissive, there was
no reason for me to be arrogant and dismissive in turn.
Having spent some time in the section of the code involving keyword expansion,
perhaps I can explain why it isn't at all trivial to do this:
All current keywords are associated with the specific file in which they are
enabled; all keywords are stored unexpanded in the server[1] and are expanded
only when writing the file to disk (this means either on checkout or export).
The $Revision$ keyword (and ones derived from it like $Id$) is well defined to
be the last revision that this specific file was changed. There is no index of
which files have keywords enabled. In fact, the working copy code is predicated
on an extremely (some might even say excessively) recursive walk through the
files, with each file being processed quite independently from the rest.
The global revision number, on the other hand, is merely the last time that
_anything_ was committed to the repository. It is not associated with any one
file (or indeed with any one project in a repo). The nominal $HEAD$ keyword
would require (as sussman pointed out) crawling through the entire working copy
just on the off chance that one or more files might contain that keyword. Not good.
Like the link you listed in the FAQ is the recommended way to deal with
checkout's, there is a similar solution for exports. The issue is that you
really want to know what the global revision number is when you perform your
export, but there is no way to easily express that with the current working copy
code. The key is to turn the question around, not "what revision is this
export" but rather "what is the lastest revision *now*, so I can specifically
export that one."
In pseudo-code:
svn info $URL => parse and extract Revision: ######
store that information in a non-source controlled file (e.g. revision.h)
svn export -r ##### (the revision number obtained from step one)
There is a race condition in that someone could make a commit between steps 1
and 3, but it is essentially harmless, since you are asking for the revision
that you have already decided to use. You have a consistent snapshot of the
repository at a point in time and more importantly, you know what global
revision your snapshot corresponds to.
John
1) OK, the base-text copies of the files are also stored unexpanded, but I'm
ignoring that for the moment since that will hopefully change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-02 05:16:30 CEST