On Oct 18, 2005, at 15:01, Detering Dirk wrote:
> Background:
> We evaluate subversion usability for our MDSD-based
> project where we generate source code
> via a code generator.
>
> The current generator is a proprietary product
> where sources are everytime overwritten except
> their dedicated user sections.
> To document the production of the current source
> we have comment lines with the generation date
> and the generator version (beside the $Id$ tag).
> So it is possible that during subsequent generator
> runs the source code changes only in this comment
> lines.
>
> Problem:
> Subversion would detect this file everytime as
> changed and wants a commit.
>
> As far as we learned subversion is able to ignore
> diffs in keywords correctly by un-substituting
> them, but OTOH will do its own predefined substitution
> when committing it (e.g. for the $Id$ tag).
> Or take it as normal content at all when not
> listed in the svn:keyword property.
>
> But:
> Is there a way to create a keyword whose content
> is not considered during diff (when checking for
> differences which need a commit), but is taken
> plainly into the repository when the file has
> changed elsewhere and is committed therefore?
I don't think Subversion can do this out-of-the-box. You could
potentially write your own diffing program to handle this situation,
and invoke it with the --diff-cmd parameter, but I think that's only
used when you call svn diff; it's not available, for example, when
you call svn commit. So you'd probably have to pre-process the
working copy on the client side before doing a commit. An algorithm
something like: get a list of every changed file ("svn st <working-
copy>"). For each file, check if the only change is the change in
your special keyword (output of "svn diff --diff-cmd <diff-cmd>" is
empty). If so, revert the file to its previous state ("svn revert
<file>"). At the end, you can commit the remaining files ("svn commit
<working-copy>").
The wisdom I've heard on this list is that things which are generated
do not belong in the repository; rather, the code that does the
generation belongs in the repository. I don't know if that can be
applied to your case.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 18 15:46:07 2005