You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bastiaan Veelo <Ba...@ntnu.no> on 2006/09/20 21:40:20 UTC
Files in repository but not version controlled
Hi,
Thanks for Subversion!
In short I would like the possibility to have some files or even
directories in the repository and make Subversion just host them and
forget about revisions when new commits are made. In other words, do not
revision control them and only store the latest revision.
I could not find anything about this in the docs or FAQ. This feature
would be handy to easily make available various generated files. Two
examples:
1) HTML documentation generated from program source by tools such as
NaturalDocs or Doxygen, as part of the build process. With the correct
mime-type this documentation can be read directly from the svn URL. But
the HTML files do not need to be version controlled, as the source files
already are.
2) Compiled example programs to illustrate a library. Visitors can
quickly evaluate the product without having to checkout, satisfy
dependencies, tweek Makefiles, build, etc., simply by pointing their
browser to the trunc. Obviously, these program files need not be version
controlled as their source already is.
This feature could be implemented as a special property, say
svn:no_history. Of course the history should not be completely erased
when this property is set, but successive intermediate revisions could
be discarded. Also, when set on a directory, new files should be
automatically added.
I am thinking whether this could be abused by a malicious user, but it
is probably not more dangerous than the svn:ignore property.
Any thoughts are welcome.
Bastiaan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Sheryl <gu...@his.com>.
Bastiaan Veelo wrote:
> In short I would like the possibility to have some files or even
> directories in the repository and make Subversion just host them and
> forget about revisions when new commits are made. In other words, do not
> revision control them and only store the latest revision.
Hi Bastiaan,
I haven't tried this, but one idea that occurs to me is to use
svn:external for the non-revisioned files and put them in their own
repository which you destroy and re-create with a script when you want to
replace the files.
Sheryl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Andy Peters <de...@latke.net>.
On Sep 21, 2006, at 6:46 AM, 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,
(snip)
I would like to point out that I _didn't_ write the above; Bastiaan did!
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Bastiaan Veelo <Ba...@ntnu.no>.
Talden wrote:
> 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 think what should happen when you check out an earlier revision is
that the hosted files should not be there. Like they never existed in
that revision. So you would not get future dated files in a checkout. I
think that the ability to evaluate generated files without even a
working copy is most valuable for the HEAD revision only. If it would
not, you could just "svn add" them.
If you check out an earlier revision it is usually to track down the
cause of a problem. If you need generated files that relate to that
revision, you can generate them in the working copy.
> 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.
The use case is to serve generated files of the HEAD revision only that
typically work without the need for a working copy (like HTML) in a
convenient way for readers and writers alike. It is a convenience,
nothing more.
> 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.
I am not interested in a working copy where files appear the same
regardless the revision.
Best regards,
Bastiaan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Talden <ta...@gmail.com>.
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 <Ba...@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
Re: Files in repository but not version controlled
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 9/22/2006 8:56 AM, Les Mikesell wrote:
> On Fri, 2006-09-22 at 05:09, Jeremy Pereira wrote:
>
>> >> 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?
>
> The real question is, how is it more dangerous for subversion
> to handle files defined as unversioned in a predictable
> way than for everyone who needs the facility to have to
> write their own ad-hoc mechanism?
Because it makes the description of what svn does more complicated.
With the current scheme, what happens with "svn up -rNNNN" is very easy
to describe: the unversioned files are left alone, the versioned files
are modified to match that revision. The result of "svn co URL; svn up
-rNNNN" is the same as the result of "svn co -rNNNN URL" and it's the
same as what you would have got from "svn co URL" back when HEAD was NNNN.
There would be no way to maintain this simplicity if svn managed files
but didn't maintain their version history. The current state of a
working copy would depend on the order in which you had checked it out
and updated it.
Having a more complicated model of what svn does would make it harder to
understand, and that would lead to mistakes, where people thought they
had one thing, but actually had another.
I think it would be
> better to have the mechanism than not, but the danger
> I see is that enabling it should really be an administrative
> function - that is, you should not permit just anyone to
> set it on random files and have it quietly throw away
> the history that other users think it is saving.
I think it's better to have tools with clean definitions of what they
do. rsync is a good tool for maintaining a mirror of a directory
without any history; svn is a good tool for maintaining files with
history. Use the appropriate tool, don't try to make one tool do
everything.
Duncan Murdoch
>> And if you are automating a checkout and build, surely it is not
>> beyond your capability to automate deletion of the intermediate build
>> products.
>
> Just because every developer can write a new, wonderful and
> bug-free way to do every operation doesn't mean it is a good
> idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Bastiaan Veelo <Ba...@ntnu.no>.
Les Mikesell wrote:
>
> the danger
> I see is that enabling it should really be an administrative
> function - that is, you should not permit just anyone to
> set it on random files and have it quietly throw away
> the history that other users think it is saving.
>
If this feature is implemented as a "svn host" command instead of a
property, that danger is greatly reduced. That is, files start and end
their lives in the repository with or without history, and never switch
between these concepts. Maybe we should not support to host a file with
a path that is identical with a versioned file that was deleted in some
earlier revision. This rules out any malicious abuse that I can think of.
Also, hosted files should be visually marked as such in the output of
svn commands.
Regards,
Bastiaan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Les Mikesell <le...@gmail.com>.
On Fri, 2006-09-22 at 05:09, Jeremy Pereira wrote:
> >> 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?
The real question is, how is it more dangerous for subversion
to handle files defined as unversioned in a predictable
way than for everyone who needs the facility to have to
write their own ad-hoc mechanism? I think it would be
better to have the mechanism than not, but the danger
I see is that enabling it should really be an administrative
function - that is, you should not permit just anyone to
set it on random files and have it quietly throw away
the history that other users think it is saving.
> And if you are automating a checkout and build, surely it is not
> beyond your capability to automate deletion of the intermediate build
> products.
Just because every developer can write a new, wonderful and
bug-free way to do every operation doesn't mean it is a good
idea.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Bastiaan Veelo <Ba...@ntnu.no>.
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
Re: Files in repository but not version controlled
Posted by Jeremy Pereira <je...@jeremyp.net>.
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
Re: Files in repository but not version controlled
Posted by Bastiaan Veelo <Ba...@ntnu.no>.
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
Re: Files in repository but not version controlled
Posted by Jeremy Pereira <je...@jeremyp.net>.
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
Fwd: Files in repository but not version controlled
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
---------- Forwarded message ----------
From: marc gonzalez-carnicer <ca...@gmail.com>
Date: 21/09/2006 14:12
Subject: Re: Files in repository but not version controlled
To: Bastiaan Veelo <Ba...@ntnu.no>
hi,
as a humble svn user, i like very much Bastiaan's
idea of a 'svn host' command.
2006/9/21, Bastiaan Veelo <Ba...@ntnu.no>:
> Andy Peters wrote:
> > On Sep 20, 2006, at 2:40 PM, Bastiaan Veelo wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Bastiaan Veelo <Ba...@ntnu.no>.
Andy Peters wrote:
> On Sep 20, 2006, at 2:40 PM, Bastiaan Veelo wrote:
>
>> Thanks for Subversion!
>> In short I would like the possibility to have some files or even
>> directories in the repository and make Subversion just host them and
>> forget about revisions when new commits are made. In other words, do
>> not revision control them and only store the latest revision.
>>
>> I could not find anything about this in the docs or FAQ.
>
> This idea goes against the whole concept of version control.
I can understand your reaction. However, I think the idea has nothing to
do with version control, and therefore does not have to go against the
concept. It would be an extension that would enhance the value of
Subversion as a development aid, by building upon some of its existing
unique features: that it uses HTTP and that it supports MIME types.
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.
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
Re: Files in repository but not version controlled
Posted by Andy Peters <de...@latke.net>.
On Sep 20, 2006, at 2:40 PM, Bastiaan Veelo wrote:
> Thanks for Subversion!
> In short I would like the possibility to have some files or even
> directories in the repository and make Subversion just host them
> and forget about revisions when new commits are made. In other
> words, do not revision control them and only store the latest
> revision.
>
> I could not find anything about this in the docs or FAQ.
This idea goes against the whole concept of version control.
-a
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Files in repository but not version controlled
Posted by Alan Ezust <al...@gmail.com>.
That's a great idea - I have a tigris project which uses a
svn-controlled directory as its actual webroot, so I have to commit
generated HTML files into the repo, and it does seem like a terrible
waste of DB space to keep all previous revisions of those generated
files.
On 9/20/06, Bastiaan Veelo <Ba...@ntnu.no> wrote:
> Hi,
>
> Thanks for Subversion!
> In short I would like the possibility to have some files or even
> directories in the repository and make Subversion just host them and
> forget about revisions when new commits are made. In other words, do not
> revision control them and only store the latest revision.
>
> I could not find anything about this in the docs or FAQ. This feature
> would be handy to easily make available various generated files. Two
> examples:
>
> 1) HTML documentation generated from program source by tools such as
> NaturalDocs or Doxygen, as part of the build process. With the correct
> mime-type this documentation can be read directly from the svn URL. But
> the HTML files do not need to be version controlled, as the source files
> already are.
>
> 2) Compiled example programs to illustrate a library. Visitors can
> quickly evaluate the product without having to checkout, satisfy
> dependencies, tweek Makefiles, build, etc., simply by pointing their
> browser to the trunc. Obviously, these program files need not be version
> controlled as their source already is.
>
> This feature could be implemented as a special property, say
> svn:no_history. Of course the history should not be completely erased
> when this property is set, but successive intermediate revisions could
> be discarded. Also, when set on a directory, new files should be
> automatically added.
>
> I am thinking whether this could be abused by a malicious user, but it
> is probably not more dangerous than the svn:ignore property.
>
>
> Any thoughts are welcome.
>
> 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