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. What if the
developer forgets to build them before doing a commit?
As a rule of thumb I would never put generated files under version
control, there are too many pitfalls. 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.
>
> Instead of my earlier proposed property, we could have a command
> instead. Like "svn host <path>". Contrary to "svn add <path>" this
> would tell Subversion to just host a file and not do version
> control on it. Newer versions of hosted files in a working copy
> would be included in a commit transaction. This way there is a
> clear separation of concepts, as files will never change between
> being version controlled and not being version controlled, unless
> they are deleted first.
>
> Best regards,
> Bastiaan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 21 15:47:25 2006