> -----Original Message-----
> From: Christian Schoenebeck [mailto:cuse_at_users.sf.net]
> Sent: donderdag 24 december 2009 13:38
> To: dev_at_subversion.apache.org
> Subject: Re: new substitution keyword for global repository revision
>
> On Thursday 24 December 2009 12:48:59 Bert Huijben wrote:
> > This solution won't work, because Subversion only updates files if they are
> > already updated for other reasons. You would have to fix that (and thereby
> > make the average update command much slower).
> >
> > Your keyword would require updating all files with this keyword, all the
> > time. And even then it wouldn't properly support mixed revision working
> > copies. (How do you plan to resolve this?)
>
> First off, I'm not yet familiar with all internals of subversion, so chances
> are high that I might miss things here and there. So please keep that in mind.
>
> With "updating all files with this keyword", do you mean updating the files in
> the repository or on WC side?
> From the knowledge I have so far, I don't see a reason to update all files on
> repository side for this task. Maybe one could even leave that keyword
> untouched in the repository representation and just incorporate the
> substitution on client side's commands. I saw there is already a function:
Currently on a 'svn update' the client receives a list of files from the repository that are updated with the information on how they are updated.
E.g. if you call 'svn update' on a working copy with 10000 files, you receive changes for just two files.
Then these files are updated and their keywords (if there are any) rewritten based on the new information.
With the new keyword you would need an additional step to walk all the other files, to check if they have your new keyword in the svn:keywords property, which is 10000-2 file opens in the current code and 10000-2 database reads in WC-NG.
And if the property for a file contains this setting the file must be rewritten with the new expansions.
Looking at the performance measurements for 1.6.x I performed some time ago, this would be a major slowdown on Windows. (Probably makes the update time 3 to 5 times longer by just opening the property files, if you have a lot of files with any keyword set).
WC-NG will probably perform better, but we can't measure that yet as the properties are not moved to the database yet. (And even then: the current DB format will not make it possible to ask for just the files with this keyword set. You still have to read all values yourself).
Bert
>
> svn_error_t *
> svn_repos_dated_revision(svn_revnum_t *revision,
> svn_repos_t *repos,
> apr_time_t tm,
> apr_pool_t *pool);
>
> Which could be used on client side to always get the latest repository
> revision and then perform the keyword substitution purely on WC client side.
> Right?
>
> About mixed revisions: yes true, that would be a problem, actually I don't
> even plan to address this issue "correctly". I would probably just stick with
> the min or max rev number or something. I rather have an imperfect
> solution,
> than no solution at all. And at the end: nobody has to use that new keyword,
> and it could be documented that its a bad implementation. It could even be
> named "StupidGlobalRevision" as keyword, I don't care, as long as I have a
> solution that works for me in practice.
>
> On Thursday 24 December 2009 13:08:32 Julian Foad wrote:
> > This has been discussed many times over the years. Have you read the
> > past discussions?
>
> I must admit, no, haven't seen that discussion yet.
>
> > > This solution won't work, because Subversion only updates files if they
> > > are already updated for other reasons. You would have to fix that (and
> > > thereby make the average update command much slower).
> >
> > With WC-NG and centralized metadata it would not necessarily be slow
> > (assuming not many files have the keyword).
>
> What does NG stand for?
>
> CU
> Christian
Received on 2009-12-24 14:23:53 CET