Re: expanding custom keywords in dump
Guten Tag Ben Reser, am Samstag, 1. Februar 2014 um 07:07 schrieben Sie: > So if you're going to critique their technique[...] I wasn't criticizing anything. Just thought that expanding $FreeBSD$ may have been a feature the FreeBSD guys patched into Subversion on their own, because some days ago it has been mentioned that FreeBSD patches subversion to get some features they need. If that is the case the questioner would need more than just svndump expanding keywords, because it would likely not support anything else than what svn clients do now. It was just a hint coming into my mind reading about the problem, no need to overestimate. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: expanding custom keywords in dump
On Sat, Feb 1, 2014 at 1:07 AM, Ben Reser 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/main.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. > Custom properties don't really make anything more difficult. Since custom > properties are repository dictated configuration. In fact the custom property > feature was written by the FreeBSD guys and then passed along upstream to ease > this burden. They're not expecting Perforce to ever expand these. They stay > literal in the source to show the base from upstream. The fact that Perforce > doesn't expand it can be considered a feature. I'd agree that Perforce's handling is correct. I'd also agree that refusing the use of *any* keywords is, generally, correct. > So if you're going to critique their technique, how about making a suggestion > of a better technique. It's like a couple guys snickering in their Ferrari as > a lorry goes by because he could have gotten there much faster in a Ferrari, > even though the driver of the lorry only has the goal to get 10 tons of > freight > there not go fast. Sorry if I sound cranky, I've been through this debate from various angles. There are, indeed, short term conveniences in the legibility of code when using keywords. But the long term consequences to stable repositories of erratic disabling and re-enabling of keyword handling, of cleaning up the accidental "diff" spew when it's handled erratically, and the difficulty of code comparison in multiple platfom projects continues to demonstrate its its awkwardness. If you need to inject localized data in your source code, such as the lat author or the upstream repository, that's what "filename.c.in" or "filename.h.in" files are for. Process the files with local build or copyright or whatever information as part of your software build process, not in the basic source code. A commented "prepend" line, in the relevant comment syntax, can be a savior and prevent internal processing of text fields that happen to match the keyword demarcations/
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 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/main.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. 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
