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.
> 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.
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 :-)
> As a rule of thumb I would never put generated files under version
> control, there are too many pitfalls.
Please elaborate.
> 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.
Having just one tree would be so much more elegant.
Best regards,
Bastiaan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 21 20:55:42 2006