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:
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 13:38:38 CET