Special Keyword for being ignored by diff during commit?

[Detering Dirk <de...@iskv.de>]

Hello all,

I'm new to the list and just searched the 
svn site and doc since a while for a specific 
problem we try to solve.

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?

Hope I could describe the problem clearly
TIA

Dirk Detering





***********************************************************************

Die Information in dieser email ist vertraulich und ist ausschliesslich 
fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
email durch andere Personen als den/die benannten Adressaten ist
nicht gestattet. Sollten Sie nicht der benannte Adressat sein, löschen
Sie bitte diese email. 

***********************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Special Keyword for being ignored by diff during commit?

[Ryan Schmidt <su...@ryandesign.com>]

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