Jeremy Pereira wrote:
>> I fail to see the extreme danger. And if you serve generated files
>> separately, outside the repository, there is no guarantee either that
>> they relate to the HEAD revision.
>
>
> You don't see the problems that might ensue if your documentation
> doesn't match your code?
>
Let us assume there is extreme danger if the documentation does not
match the code. Then of course a developer that changes the code, also
checks that the corresponding block of documentation (which is typically
embedded in the source file in the scenario of generated documentation)
still applies. If it does not, he also makes changes to the
documentation block.
Do you assume that the developer commits without generating any files at
all? I guess not, because he might bring the HEAD revision in an
uncompilable or otherwise erroneous state. Why would he then just
compile and link and not generate the documentation, if he changed both
the source of the object file and of the documentation?
It usually is important to have a clean HEAD revision, so people usually
"make all" before they commit. If a project has hosted files then of
course "make all" should regenerate hosted files that have become out-dated.
>
> Then there is the issue that you cannot guarantee that the platform
> you check out on is the same as the platform the generated files were
> created on. Imagine if the Subversion repository had the binaries in
> it built for 386 and Linux but I was running on Power PC and OS X?
Good point. The example of executables does not apply to cross-platform
development.
>>> A far better idea would be to maintain a working copy in your web
>>> server's DocRoot and have it automatically update and build in a
>>> post commit hook or cron job.
>>
>> I know that trick, but then we would serve two almost identical
>> document trees: the working copy and the repository. And just
>> building would not be enough, we should not forget to call "make
>> clean" to remove all the .o files that we do not want the served tree
>> be cluttered with. Rebuilding all projects in a repository upon each
>> commit is a waste of resources. Besides, there is a real possibility
>> that someone browses the documentation during the build process,
>> which could give an ugly user-experience.
>
> The document tree would not be in the repository, only the files used
> to generate it.
Of course. I meant file trees.
>
> And if you are automating a checkout and build, surely it is not
> beyond your capability to automate deletion of the intermediate build
> products.
Of course not. But as I said, if you delete intermediate build products
then the build is likely to take longer than you are willing to spend
time on upon each commit. So you would have the delay of a cron job.
> Also, there are plenty of techniques you can use to achieve the
> appearance of atomicity for the working copy e.g. build it somewhere
> else and move it to the DocRoot or only check out and build it at 4am
> in the morning.
Of course there are ways to get generated files out to the world at
regular intervals. It is just that in some peoples eyes having
Subversion host them would be a nice convenience.
> What you've asked for compromises the elegance of the conceptual model
> of Subversion itself.
OK.
Best regards,
Bastiaan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 22 13:54:42 2006