Re: Files in repository but not version controlled

What happens when you checkout an earlier revision? You get a file
that is dated dramatically in the future whose content may not be
relevent to the checked out version.

I'd like to see the use-case that makes this facility valuable before
a feature that seems to be nothing more than a server filesystem added
to Subversion. Can anyone provide a concise example of a mixed
environment where some files should appear the same regardless of the
working-copy revision? It does seem as though externals might be able
to do what's needed instead.

--
Talden
On 9/22/06, Bastiaan Veelo <Bastiaan.N.Veelo@ntnu.no> 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.
>
> >   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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org