[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS/SVN comparison

From: John Szakmeister <john_at_szakmeister.net>
Date: 2004-10-23 00:14:00 CEST

Scott Palmer wrote:
> On Oct 22, 2004, at 3:58 PM, David F. Newman wrote:
>
>> On Fri, 2004-10-22 at 15:15, Scott Palmer wrote:
>>
>>>
>>> Um, that's *MY* point. :)
>>> Subversion doesn't do immutable copies. Apache can be configured to
>>> work around this issue. I simply think that *Subversion* should
>>> support immutable copies as I think it would satisfy many people that
>>> are looking for a kind of tag that Subversion currently doesn't have.
>>
>>
>> Just because the subversion server that runs inside apache has more
>> features than the subversion server that runs outside apache doesn't
>> mean that it is a hack done with apache to work around the issue. It's
>> still a feature of subversion and not apache.
>
>
> Dang it... I'm not supposed to be replying anymore... :)
>
> I disagree.
> In this case it isn't subversion that has the feature at all. The
> feature is handled by apache. It's a subtle point, but a point none the
> less. The url I use to access the repository shouldn't have anything to
> do with what is or is not allowed. That's just plain bad design.
>
>> If you don't allow a
>> directory to be updated than as far as I'm concerned it is immutable.

Again, you can do this with a pre-commit hook, without any dependencies
on Apache.

> Right.. but subversion doesn't let you do that with svnserve or file:
> urls. You need to install a 3rd party product called Apache - which
> drags in a whole bloody web server, just for source control.
>
>> The point is that subversion is letting you make that decision instead
>> of telling you how it's going to be.
>
>
> No it isn't. It is absolutely telling me how it's going to be. It's
> saying "tough, subversion doesn't do this. You need to install Apache,
> an entirely different product, and access the repository in a different
> way, because the repository doesn't support what you want at all. You
> need some extra layer on top of subversion to do that for you. That's
> how it's going to be! You can forget about using file: or svn: access
> methods, and you can forget about not installing Apache, now you have no
> choice."

Not true. Just because it doesn't provide you with the concept right
there on the command line through a switch, doesn't mean a feature isn't
there. Again, a pre-commit hook lets me enforce my own policy about how
I want tags to behave, if I even want them at all.

Let me point out that this didn't work in CVS. I could move a tag, and
that makes them mutable. The contents the tag represented is now different.

> Well it would be like that if the commit-hooks don't work. :)
>
> I'm still not sure of how they work. How does a commit hook run when I
> access the repository through a file: url?? Does it mean I have to have
> python installed on every computer I access the repository from if I use
> the supplied python script? (Which would be completely unacceptable to
> me.) Do they work any differently if I use svnserve?

Commit hooks work fine through both file:// and svn:// access. If you
want to use the supplied python script, and use file:// access (which I
don't recommend), then yes you would need to have python installed on
the machine. If you accessed the repository with svn:// access, you
would only need python on the server.

If you don't want it python, it isn't hard to write a script in bash. I
did it, and I'm no shell scripting wizard. I'd post it out here, but
getting files out of a classified environment is next to impossible.

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Oct 23 00:14:36 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.