> -----Original Message-----
> From: Branko Èibej [mailto:brane_at_wandisco.com]
> Sent: 02 February 2014 06:42
> To: users_at_subversion.apache.org
> Subject: Re: expanding custom keywords in dump
>
> On 02.02.2014 04:14, Nico Kadel-Garcia wrote:
> > On Sat, Feb 1, 2014 at 1:07 AM, Ben Reser <ben_at_reser.org> wrote:
> >
> >> Branko gave a perfectly reasonable answer. Beyond that I honestly
> >> don't get the point of these two emails. FreeBSD uses keywords
> >> because as an open source project they ship source. Even more
> >> importantly they have downstream projects (e.g. Apple uses
> their find
> >> command
> >>
> http://opensource.apple.com/source/shell_cmds/shell_cmds-175/find/mai
> >> n.c ). I can't think of a better way of tracking
> versioning for them
> >> once the source leaves their version control system and
> potentially goes into another. Yes there are all sorts of
> annoying bits about this.
> > If your build system has to rely on source control based fields,
> > process the code in your build system. Putting the keyword
> processing
> > in the source control itself certainly dates back ti RCS
> and CVS, and
> > has been the bane of comparing source trees in working
> copies, and of
> > of actually reviewing the source control that will be used for
> > building software. It profoundly interferes with generating
> > replicatable code in multiple build or test environments.
>
> You're totally missing the point of this thread. No-one said
> anything about build systems; the original poster's
> requirement is tracking upstream versions of files, not
> complete source trees. No amount of *.h.in magic is going to do that.
>
> Obviously, in an ideal world, one would be able to migrate
> these kind of metadata between different VCS. Likewise
> obviously, the world is not ideal, and in-file keywords are a
> reasonable alternative if no other tooling can be devised. In
> the case of Subversion->Perforce migration, one could argue
> that it's Perforce's fault for not having an equivalent to
> Subversion's properties that could store the source repo metadata.
http://www.perforce.com/perforce/r12.1/manuals/cmdref/attribute.html
> Compared to inventing a separate-but-parallel database for
> maintaining these metadata, and all the surrounding tooling
> that this implies, expanded keywords in the files themselves
> appear positively benign, especially when they're not going
> to change except from further upstream imports.
>
> Last but not least ... Subversion does not expand keywords
> unless explicitly told to. This was a conscious decision we
> made to discourage exactly the kind of abuse you're griping
> against. But you'll have a hard time to find a single VCS
> glove that fits all potential users' feet.
>
> -- Brane
>
>
> --
> Branko Èibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email
> Security.cloud service.
> For more information please visit
> http://www.symanteccloud.com
> ______________________________________________________________________
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3681/7023 - Release
> Date: 01/21/14 Internal Virus Database is out of date.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
Received on 2014-02-03 13:38:49 CET