On 21 Sep 2006, at 19:21, Bastiaan Veelo wrote:
> Jeremy Pereira wrote:
>>
>> On 21 Sep 2006, at 12:34, Bastiaan Veelo wrote:
>>
>>> Andy Peters wrote:
>>>
>>> Obviously not all files in a project need to be under version
>>> control, illustrated by the property svn:ignore. But some of
>>> these files are still interesting for others to see, like
>>> generated documentation and statically linked example
>>> executables. Of course it is no problem to serve these on a web
>>> site, but it requires publishing new versions which is a hassle
>>> especially if there are multiple developers, and it would be much
>>> more natural for visitors if they can find these files side by
>>> side the source of the project, just as they appear after a
>>> checkout and make, by pointing their browser at the trunc. People
>>> can have it this way already by "svn add"ing these generated
>>> files, but version controlling them is a waste of space. I think
>>> that the value of being able to see files from the HEAD of a
>>> repository by visiting http://example.com/svn/trunc/ with an
>>> ordinary web browser would be greatly increased with this feature
>>> --- often documentation is much more interesting to read than the
>>> source itself.
>>
>> I think this is an extremely dangerous idea because there is no
>> guarantee that the HEAD revision of the generated files are the
>> ones that relate to the HEAD revision of the source files.
>
> 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?
>
>> What if the developer forgets to build them before doing a commit?
>>
> The same as when a developer forgets (or just does not bother
> because of the trouble he should get through) to publish the
> generated files to a web site: the documentation could be out-of-
> sync with the library in HEAD or the example executable could be
> out of sync with the source of the example and/or library in HEAD.
> No severe consequences that I can think of.
If you had read my solution you would understand that the publishing
is an automated process. The post commit hook fires after every
commit. The process is taken right out of the developers' hands.
>
> In fact I think the chances for outdated generated files are much
> higher when they are served outside the repository. These hosted
> files would be generated as part if "make all", and doing make all
> is just good practice before doing a commit. Developers need not
> think about publishing generated files and need not track which
> files have actually changed because this wonderful tool called
> Subversion just takes care of it :-)
If you had read my solution you would understand that the publishing
is an automated process. The post commit hook fires after every
commit. The process is taken right out of the developers' hands.
Your assertion that "Subversion takes care of it" is false because
the developer has to run a build immediately before commit.
>
>> As a rule of thumb I would never put generated files under version
>> control, there are too many pitfalls.
>
> Please elaborate.
I think the "generated file is not in sync with the source code"
pitfall is serious enough on its own.
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?
>
>> 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.
And if you are automating a checkout and build, surely it is not
beyond your capability to automate deletion of the intermediate build
products.
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.
>
> Having just one tree would be so much more elegant.
I've given you a solution to get one tree: create working copy
automatically and ignore the repository tree for browsing.
What you've asked for compromises the elegance of the conceptual
model of Subversion itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 22 12:09:53 2006