[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Keyword substuition question

From: David Weintraub <qazwart_at_gmail.com>
Date: Mon, 22 Sep 2008 10:14:09 -0400

Multiple line keyword substitutions is a major issue. It is impossible
to tell what lines were inserted due to the keyword expansion and what
lines were inserted by the user. Then, there is the issue that when
you expand it, how do you make sure you don't cause issues with the
code.

This makes it very difficult to store unexpanded keywords in the
source repository in order to make merging and diffing work.
Therefore, any sort of keyword expansion beyond the single line cannot
be done. $Copyright$ could be done, but a long license description is
not possible. Replacing a "$License$" keyword beyond a short phase
would be impossible to handle.

Nor, do I recommend doing anything to automate the process because
that breaks the process. The only way around this is to automatically
checkout the code that was just checked in, expand the custom keyword,
then do a second commit. Your history would be full of these automatic
commits, the person who did the change would find their current
workspace out of date, and merging and diffing become more difficult.

If you want to do this type of expansion, I highly recommend you do
this at build time or package time (if you're packaging source). That
way, you don't glop up your development environments with double
commits, and you don't have to twist and pull Subversion until it
breaks in order to support it. Expansion on build or packaging can
easily be done using Make or Ant.

You'll find that doing keyword expansion during the build/package
stage will be easier to implement and less problematic with diffing
and merging than attempting to do this inside the version control
system.

--
David Weintraub
qazwart_at_gmail.com
On Mon, Sep 22, 2008 at 9:38 AM, Roger Lipscombe <rogerl_at_1e.com> wrote:
> We had a similar problem (at a previous company) -- when we shipped our stuff to escrow, or we packaged our GPL-licensed stuff, we wanted to make sure that the copyright/license information at the top of the file was correct.
>
> In the end, we used a custom export script, which knew to replace $License$ with some boilerplate.
>
> That is: we did it at export time, rather than in the repository.
>
> Cheers,
> Roger.
>
> -----Original Message-----
> From: Joe Wade [mailto:d.joe.wade_at_gmail.com]
> Sent: Mon 22 September 2008 13:25
> To: users_at_subversion.tigris.org
> Subject: SVN Keyword substuition question
>
> Have a SVN useage question.  Ultimately I am looking to perform a custom
> keyword substuition.  But as I do not think that is currently supported
> (issue 890 seems like people are trying), I may need some help with a
> work around.
>
> I would like (or at least the powers that be would like) to append a
> license and copyright statement to the top of every source & header
> file.  I don't really want to manually edit all the files for a few
> reasons.  First, I don't want to have to maintain the files as the
> statements change (which they shouldn't but of course will).  There
> are also quite a few files (big project), so I don't really want to
> go through all the files manually.
>
> I have investigated using svn:property(s) (as the book suggests)
> to embedd license and copyright information, but I really need them
> to be visible at the top of each of the files.  The properties are only
> (correct me if I am wrong) through the svn prop* commands.
>
> I could create a sed script (or something) to put the statements at
> the top of the file, but I am hoping there is a nicer way for me
> to do this with SVN.  I think the ultimate solution would be to have
> a $license$ and $copyright$ keyword on the files and have SVN
> do a substuition during checkout/checkin, but in the meantime I
> need to get this done.  Any ideas?  Can I get this functionality with
> the current set of hook scripts?
>
> --
> V/R,
> Joe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
>
> DISCLAIMER:  This is a PRIVATE AND CONFIDENTIAL message for the ordinary user of this email address.  If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.  NOTE:  Regardless of content, this e-mail shall not operate to bind 1E Ltd to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-22 16:14:29 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.