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
Received on Fri Sep 22 15:12:00 2006