> -----Original Message----- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: 02 February 2014 06:42 > To: users@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 <b...@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. br...@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 ______________________________________________________________________
