Hi guys,
I have wondered about the absence of this feature for a while. However,
my use case is somewhat simpler.
I only ever require the revision of the working copy/export when
exporting the codeset, rather than a checkout.
We use exports to use as the basis for the builds, and in our version.*
file, we include the revision that was used.
Would it be possible to introduce certain keywords that are expanded
only on export e.g $ExportRevisionID$? Probably not, but it's just a
thought.
Cheers,
Daniel B.
> -----Original Message-----
> From: Branko Cibej [mailto:brane_at_xbc.nu]
> Sent: Friday, 2 May 2008 8:38 AM
> To: Jamax
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Revision number in source, exported
>
> Jamax wrote:
> > So this information cannot be put in the entries files?
> They are being opened twice for every folder in the working
> copy anyway during an svn update.
> >
>
> It's technically possible to do that, but because of
> assumptions made throughout the working copy code, doing that
> would probably be more work than the benefit's worth. In
> other words, it makes more sense to work on the new
> generation working copy (which, presumably, would make such a
> feature easier to implement) than to try to retrofit (and
> debug!) it in the current implementation. Yes, we know, our
> working copy implementation produces a strong decreasing
> pressure gradient.
>
> Another thing here is that, performance-wise, it would not be
> enough to quickly find all file that have HEAD in
> svn:keywords; it's common practice set the same svn:keywords
> on most files. We'd have to flag files that actually contain
> that keyword (and keep the flag up to date during version
> conortions). That's an order of magnitude more complex to get
> right, and unless a case can be made for having such a
> keyword-instance (or file-content-pattern) cache as a more
> generic mechanism, i strongly doubt it's worth the effort to
> implement for just $HEAD$ expansion.
>
> Then of course there's the question whether $HEAD$ even makes
> sense in general, because its value would reflect commits to
> unrelated branches or even completely different projects in
> the same repository.
>
> -- Brane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
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 04:36:32 CEST