Andy Levy wrote:
> On 12/23/05, Eduardo Elias Camponez <camponez@uai.com.br> wrote:
...
>>First of all, sorry my bad english. :-)
...
>>Let me explain:
>>
>>I have a foo.c and bar.c files that are (re)genarate by a script.
>>I need that those files have the same hash version. Hash version in this
>>case is a line with numbers and letters (something like md5 key).
>>Everytime script needs to regenarate those files it make a new key and
>>write in particular place of each file (foo.c and bar.c)
>
> If foo.c and bar.c can always be generated by a script that's also in
> your project, should foo.c and bar.c be versioned at all?
In a case like this, I think the best solution is to use a pattern that
separates the changing code and the generated code.
A common approach is to rename foo.c and bar.c as foo.c.in and bar.c.in.
These are the files that get checked into the repository, and will always
contain just the //VERSION text without the hash (i.e. enough to allow the
script to regenerate them). The script will then take foo.c.in and
bar.c.in, and generate foo.c and bar.c from them. The downside of this
is that maintainers need to remember to edit the .in files and not
the .c files, but it's often possible to rig the build script to avoid
this problem most of the time.
But since the files are .c files (assuming that the .c wasn't only for
the sake of the example), an even better approach is to just move the
lines in question into a separate .h file, which never gets checked
into the repository, and use a #include line into the two .c files
to fetch the contents. Some systems use the extension ".hh" to
distinguish generated files from the ordinary .h file.
> One thing I read somewhere early in my svn research (it may not have
> been an SVN book, maybe just a generic "best practices" for source
> control) was "don't version things that can be generated".
It's a good rule of thumb, but it's not a best practice. There are
situations where checking in generated items makes sense.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 25 00:43:44 2005