You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Pavel Roskin <pr...@gnu.org> on 2002/09/25 21:01:03 UTC
[PATCH] Additions to INSTALL
Hello!
I'm just starting using Subversion, and this patch adds pieces that were
not immediately obvious for me when I tried to install the server.
=====================================
--- INSTALL
+++ .svn/tmp/INSTALL.62812.00001.tmp Wed Sep 25 16:57:33 2002
@@ -743,6 +743,10 @@
directives. Full details on setting up apache can be found at:
http://httpd.apache.org/docs-2.0/
+ Add this line after the last LoadModule directive:
+
+ LoadModule dav_fs_module modules/mod_dav_fs.so
+
Add this to the *bottom* of /usr/local/apache2/conf/httpd.conf:
<Location /svn/repos>
@@ -819,11 +823,18 @@
D. Running and Testing
-------------------
+ Initialize the repository. This is described in the README file.
+
Fire up apache 2.0:
$ /usr/local/apache2/bin/apachectl stop
$ /usr/local/apache2/bin/apachectl start
+ On Red Hat, you might need to use following commands instead:
+
+ $ service httpd2 stop
+ $ service httpd2 start
+
Check /usr/local/apache2/logs/error_log to make sure it started
up okay.
=====================================
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Additions to INSTALL
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 25 September 2002 23:20
> Pavel Roskin <pr...@gnu.org> writes:
[...]
>> + Add this line after the last LoadModule directive:
>> +
>> + LoadModule dav_fs_module modules/mod_dav_fs.so
>> +
>
> Huh? Why would we need the mod_dav_fs backend to mod_dav?
Indeed. It isn't needed.
>> D. Running and Testing
>> -------------------
>>
>> + Initialize the repository. This is described in the README file.
>> +
>
> Um, at the top of section C, we have:
>
> C. Configuring Apache for Subversion
> ---------------------------------
>
> The following assumes you have already created a repository.
> For documentation on how to do that, see README.
>
> Should we also put it in section D?
Given that Pavel is number two complaining about it (Ryan Bloom was first),
we probably should ;)
>
>> Fire up apache 2.0:
>>
>> $ /usr/local/apache2/bin/apachectl stop
>> $ /usr/local/apache2/bin/apachectl start
>>
>> + On Red Hat, you might need to use following commands instead:
>> +
>> + $ service httpd2 stop
>> + $ service httpd2 start
>> +
>
> Ah, this seems nice...
-1. No more platform specific instructions please. If we add this for
RedHat, we also have to do it for Debian and others.
> but this whole document assumes you're building
> apache2 from source code, and installing into some prefix. How does
> the redhat 'service' program know where to find your freshly built and
> installed httpd-2.0?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
> > I'm used to the idea "commit it or lose it", i.e. the working
> > directory is an extremely unsafe place to keep my changes. If I spend
> > 20 minutes or more editing some file, and I cannot commit it (i.e.
> > it's still not ready), I make a copy outside the tree.
>
> Besides other reasons, I use a SCM so that I need _not_ to copy sources
> around to arbitrary places and forgetting the context in which they were
> created.
You don't need to copy sources around. Save the patches if you cannot or
don't want to apply them.
> > Other people may take a different approach, and they will suffer.
> > They are suffering with CVS already, because "cvs up" merges files
> > without asking permission, and there is no way to disable merge on
> > update from the command line.
>
> Huh? They _asked_ for merge when they issued "cvs up", since "cvs up"
> actually _means_ to merge...
It means to update the sources and merge if necessary. The bad thing,
merge is often unexpected and requires manual work to recover from.
> > > I'd rather check the output of "svn st | grep '^?'" for important files.
> > It should be safe in many cases to remove files that svn ignores.
>
> How come you to deduce this? Any ignored files after "make clean"
> deserve my attention. There are exactly three possibilities how such
> files can spring in existance:
>
> 1. I forgot to add them to the "make clean" target
> 2. I forgot to "svn add" them.
> 3. I created them so I have input/output-data for test-runs.
That's right. But sometimes you just know that there is nothing
interesting in the working directory that could not be easily reproduced.
> > I believe that it would be nice to extend "svn cleanup" or "svn revert" to
> > remove non-versioned files.
>
> There were examples posted to this thread how you could do this with a
> little help from perl/sed/xargs.
I'm using such script already. My point is that it would be nice to have
a command for that.
> > The reason is that the presence on versioned files limits my ability
> > to work with files using standard UNIX commands.
>
> Huh? Could you please explain this in detail?
I omitted the obvious "if I don't want to interfere with the integrity of
the working directory and the repository".
The repository is fortunately well protected by the client-server
protocol, but the working directory is not protected. It is not like
Clearcase, when you mount the directory and the kernel tells you want you
can do and what you cannot do with the versioned files.
> > I cannot remove non-versioned files by "rm -rf".
>
> Huh? Why not? There is nothing that keeps you from "rm -rf WC". If you
> want to reconstruct the state as it was on checkout (as you mentioned
> on your prevous mail), you could issue
>
> cd ..; rm -rf WC; svn co -r X http://never.mind/foo WC; cd WC
>
> to get a really clean wc.
Firstly, it removes my local changes to the versioned files, something
that I may or may not wish. Secondly, it's impractical for large projects
and narrow data pipes.
> > Compare this to the editor - presence of versioned files doesn't
> > affect my ability to edit any files.
I meant, svn is designed is such way that it doesn't go crazy if I edit
the files under version control without locking. It is also tolerant to
the files it doesn't know about.
> And it doesn't affect your ability to manipulate them in any other
> way. This restriction exists only in your mind.
Again, I meant "without breaking the integrity of the versioning system".
> > That's especially true, since svn is aware of the ignored files, and
> > it often makes sence to remove only ignored files (i.e. keep the new
> > sources, but clean the build).
>
> It might make sense in some rare situations. But in those situations
> the posted solutions with help from perl/sed/xargs are possible.
Our development style is different. What is rare for you is common for
me.
> > Otherwise, I'll have to write Subversion Utilities, and post them on
> > my homepage near CVS Utilities.
>
> Please do this. And please do not introduce redundant functionality
> which would needlessly bloat the clean design of svn.
Ok.
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Josef Wolf <jw...@raven.inka.de>.
On Thu, Sep 26, 2002 at 05:55:14PM -0400, Pavel Roskin wrote:
> > This doesn't look like a good approach to solve that specific problem.
> > If I forgot to include with "svn add" some source file created by hand,
> > the last thing I'd like to do is to remove that file. :-)
Well said!
> I'm used to the idea "commit it or lose it",
> i.e. the working directory is an extrement unsafe place to keep my
> changes. If I spend 20 minutes or more editing some file, and I cannot
> commit it (i.e. it's still not ready), I make a copy outside the tree.
Besides other reasons, I use a SCM so that I need _not_ to copy sources
around to arbitrary places and forgetting the context in which they
were created.
> Other people may take a different approach, and they will suffer. They
> are suffering with CVS already, because "cvs up" merges files without
> asking permission, and there is no way to disable merge on update from the
> command line.
Huh? They _asked_ for merge when they issued "cvs up", since "cvs up"
actually _means_ to merge...
I was suffering with CVS, but this was definitely _not_ for _this_
reason.
> > I'd rather check the output of "svn st | grep '^?'" for important files.
> It should be safe in many cases to remove files that svn ignores.
How come you to deduce this? Any ignored files after "make clean"
deserve my attention. There are exactly three possibilities how such
files can spring in existance:
1. I forgot to add them to the "make clean" target
2. I forgot to "svn add" them.
3. I created them so I have input/output-data for test-runs.
In the first two cases, I should fix my source. In the third case
(which happen rarely), I delete them when _I_ want. Chances are that I
even decide to "svn add" them after some modifications and extend
regression-tests this way. No need for automated deletion at all.
> I believe that it would be nice to extend "svn cleanup" or "svn revert" to
> remove non-versioned files.
There were examples posted to this thread how you could do this with a
little help from perl/sed/xargs.
> The reason is that the presence on versioned
> files limits my ability to work with files using standard UNIX commands.
Huh? Could you please explain this in detail?
> I cannot remove non-versioned files by "rm -rf".
Huh? Why not? There is nothing that keeps you from "rm -rf WC". If you
want to reconstruct the state as it was on checkout (as you mentioned
on your prevous mail), you could issue
cd ..; rm -rf WC; svn co -r X http://never.mind/foo WC; cd WC
to get a really clean wc.
> Compare this to the
> editor - presence of versioned files doesn't affect my ability to edit
> any files.
And it doesn't affect your ability to manipulate them in any other
way. This restriction exists only in your mind.
> If svn takes "rm -rf" away from me, it should offer a replacement.
It doesn't take away "rm -rf" and it shoudn't offer replacements.
> That's
> especially true, since svn is aware of the ignored files, and it often
> makes sence to remove only ignored files (i.e. keep the new sources, but
> clean the build).
It might make sense in some rare situations. But in those situations
the posted solutions with help from perl/sed/xargs are possible.
> Otherwise, I'll have to write Subversion Utilities, and post them on my
> homepage near CVS Utilities.
Please do this. And please do not introduce redundant functionality
which would needlessly bloat the clean design of svn.
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
Hello, Gustavo!
> > 3) Do both. Good for automated scripts that create snapshots. Good for
> > starting from scratch.
>
> This doesn't look like a good approach to solve that specific problem.
> If I forgot to include with "svn add" some source file created by hand,
> the last thing I'd like to do is to remove that file. :-)
You are right. I'm usually careful not to do it, but I have had this
problem too.
The fact is, different people have different styles of working with
version control systems. I'm used to the idea "commit it or lose it",
i.e. the working directory is an extrement unsafe place to keep my
changes. If I spend 20 minutes or more editing some file, and I cannot
commit it (i.e. it's still not ready), I make a copy outside the tree.
Other people may take a different approach, and they will suffer. They
are suffering with CVS already, because "cvs up" merges files without
asking permission, and there is no way to disable merge on update from the
command line.
> I'd rather check the output of "svn st | grep '^?'" for important files.
It should be safe in many cases to remove files that svn ignores. As for
the files that are not ignored, it depends.
I believe that it would be nice to extend "svn cleanup" or "svn revert" to
remove non-versioned files. The reason is that the presence on versioned
files limits my ability to work with files using standard UNIX commands.
I cannot remove non-versioned files by "rm -rf". Compare this to the
editor - presence of versioned files doesn't affect my ability to edit
any files.
If svn takes "rm -rf" away from me, it should offer a replacement. That's
especially true, since svn is aware of the ignored files, and it often
makes sence to remove only ignored files (i.e. keep the new sources, but
clean the build).
Otherwise, I'll have to write Subversion Utilities, and post them on my
homepage near CVS Utilities.
I really hope that I'll not have to do so, because Subversion is natively
client-server, and already supports a number of local-only operations
(e.g. "svn add"), unlike cvs, where every command involves server in some
way, so doing something purely local would be unusual.
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Gustavo Niemeyer <ni...@conectiva.com>.
Hi Pavel!
> I want to remove all files and directories that are not versioned. It's
> quite common that some files (or symlinks) are created by hand, then the
> developer forgets about it, and the build works for that developer, but
> not for anybody else, who don't have that file or symlink.
>
> The best way to resolve this situation is to do a clean build. Things
> like "make distcheck" help too, but it's doesn't work for projects that
> don't use Automake (one of the projects is a Linux kernel driver).
>
> There are actually three different things that I occasionally want to do:
>
> 1) Revert changes in the versioned files (that's what "svn revert" does).
>
> 2) Remove all non-versioned files. Good for checking my changes before
> the commit.
>
> 3) Do both. Good for automated scripts that create snapshots. Good for
> starting from scratch.
This doesn't look like a good approach to solve that specific problem.
If I forgot to include with "svn add" some source file created by hand,
the last thing I'd like to do is to remove that file. :-)
I'd rather check the output of "svn st | grep '^?'" for important files.
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Scott Lamb <sl...@slamb.org>.
Garrett Rooney wrote:
> Rafael Garcia-Suarez wrote:
>> svn status --no-ignore | perl -lne '/^\?\s*(.*)/ and unlink $1'
>
> that won't work for directories.
Plus, it doesn't print out errors. Though I guess
"(unlink $1 or warn "Can't unlink $1: $|)" would solve that.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > svn status --no-ignore | perl -lne '/^\?\s*(.*)/ and unlink $1'
>
> that won't work for directories.
D'oh, yes. So fallback to xargs. I see that svn usefully reports only
the unrecognized directory, not its contents : cool. (sorry for the
noise, couldn't resist)
...| perl -l0ne 's/^\? *// and print' | xargs -0 rm -f
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Rafael Garcia-Suarez wrote:
> Scott Lamb <sl...@slamb.org> wrote:
>
>>Philip Martin wrote:
>>
>>>$ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
>>
>>I would like to point out that this is not safe if filenames contain
>>spaces. Untested command that should be safer:
>>
>>svn status --no-ignore \
>>| perl -ne 'chomp; s/\? // and print, "\0"' \
>>| xargs -0 rm -rf
>
>
> This doesn't work, this should be at least s/^\? +// because there
> are several spaces, and print "$_\0".
> But of course perl can do the unlink by himself.
>
> svn status --no-ignore | perl -lne '/^\?\s*(.*)/ and unlink $1'
that won't work for directories.
-garrett (who was trying to figure out how to do this last night)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Rafael Garcia-Suarez <ra...@hexaflux.com>.
Scott Lamb <sl...@slamb.org> wrote:
> Philip Martin wrote:
> > $ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
>
> I would like to point out that this is not safe if filenames contain
> spaces. Untested command that should be safer:
>
> svn status --no-ignore \
> | perl -ne 'chomp; s/\? // and print, "\0"' \
> | xargs -0 rm -rf
This doesn't work, this should be at least s/^\? +// because there
are several spaces, and print "$_\0".
But of course perl can do the unlink by himself.
svn status --no-ignore | perl -lne '/^\?\s*(.*)/ and unlink $1'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Scott Lamb <sl...@slamb.org>.
Philip Martin wrote:
> $ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
I would like to point out that this is not safe if filenames contain
spaces. Untested command that should be safer:
svn status --no-ignore \
| perl -ne 'chomp; s/\? // and print, "\0"' \
| xargs -0 rm -rf
(Requires perl (probably possible with sed; I don't know how) and an
extended xargs (GNU and FreeBSD's both work).)
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Roman Neuhauser <ne...@bellavista.cz>.
# pathu440@student.liu.se / 2002-09-26 08:54:21 +0200:
> Ben Collins-Sussman wrote:
> >Pavel Roskin <pr...@gnu.org> writes:
> >>>The rest is not really version control
> >>>
> >>>$ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
> >>
> >>or simply:
> >>
> >>svn st --no-ignore | sed -ne 's/^?//p' | xargs rm -rf
>
> >Remind me: did we all agree that this *wouldn't* be a new subcommand?
>
> is this possible in win32 and other non-*nix environments.
> I know the win2k/xp command-prompt is a a lot more powerful that most
> people think, but is it possible without installing such tools as "sed"
> and "xargs" neither of which I know what does.
that depends on those environments.
http://unxutils.sourceforge.net/
http://www.gnu.org/manual/manual.html
subversion's goal is not to replace inadequate shells.
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
12:49PM up 8 days, 20:04, 21 users, load averages: 0.08, 0.08, 0.02
end
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Patrik Husfloen <pa...@student.liu.se>.
is this possible in win32 and other non-*nix environments.
I know the win2k/xp command-prompt is a a lot more powerful that most
people think, but is it possible without installing such tools as "sed"
and "xargs" neither of which I know what does.
/patrik
Ben Collins-Sussman wrote:
> Pavel Roskin <pr...@gnu.org> writes:
>
>
>>>The rest is not really version control
>>>
>>>$ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
>>
>>or simply:
>>
>>svn st --no-ignore | sed -ne 's/^?//p' | xargs rm -rf
>
>
>
> Remind me: did we all agree that this *wouldn't* be a new subcommand?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Ben Collins-Sussman <su...@collab.net>.
Pavel Roskin <pr...@gnu.org> writes:
> > The rest is not really version control
> >
> > $ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
>
> or simply:
>
> svn st --no-ignore | sed -ne 's/^?//p' | xargs rm -rf
Remind me: did we all agree that this *wouldn't* be a new subcommand?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
> The rest is not really version control
>
> $ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
or simply:
svn st --no-ignore | sed -ne 's/^?//p' | xargs rm -rf
Thank you very much!
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Philip Martin <ph...@codematters.co.uk>.
Pavel Roskin <pr...@gnu.org> writes:
> 2) Remove all non-versioned files. Good for checking my changes before
> the commit.
The subversion bit is
$ svn st --no-ignore
The rest is not really version control
$ svn st --no-ignore | grep ^\? | cut -c2- | xargs rm -rf
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
> > I'm still undecided whether to move some of my projects to Subversion. I
> > miss a command to clean up everything and return the working directory to
> > the original state. Compiling from a "reused" directory feels like eating
> > from a "reused" plate.
>
> Huh? I'm not following what you want to do.
I want to remove all files and directories that are not versioned. It's
quite common that some files (or symlinks) are created by hand, then the
developer forgets about it, and the build works for that developer, but
not for anybody else, who don't have that file or symlink.
The best way to resolve this situation is to do a clean build. Things
like "make distcheck" help too, but it's doesn't work for projects that
don't use Automake (one of the projects is a Linux kernel driver).
There are actually three different things that I occasionally want to do:
1) Revert changes in the versioned files (that's what "svn revert" does).
2) Remove all non-versioned files. Good for checking my changes before
the commit.
3) Do both. Good for automated scripts that create snapshots. Good for
starting from scratch.
> Are you looking for 'svn revert'?
Probably not. It doesn't seem to affect non-versioned files:
[proski@marabou rxvt]$ ls Makefile
Makefile
[proski@marabou rxvt]$ svn revert Makefile
svn: Can't find an entry
svn: Cannot revert 'Makefile' -- not a versioned resource
[proski@marabou rxvt]$ ls Makefile
Makefile
[proski@marabou rxvt]$
I really hope that Subversion won't need addons to do such simple things.
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Ben Collins-Sussman <su...@collab.net>.
Pavel Roskin <pr...@gnu.org> writes:
> > Huh? Why would we need the mod_dav_fs backend to mod_dav?
>
> I'm sorry. I meant this line:
>
> LoadModule dav_svn_module modules/mod_dav_svn.so
'make install' within subversion installs that line automatically.
That's why we don't have it listed as something you need to do.
But I see you're using RPMs, so it seems many things are suddenly
different than what the INSTALL instructions expect...
> I'm still undecided whether to move some of my projects to Subversion. I
> miss a command to clean up everything and return the working directory to
> the original state. Compiling from a "reused" directory feels like eating
> from a "reused" plate.
Huh? I'm not following what you want to do.
Are you looking for 'svn revert'?
> Oh, by the way, you might want to add this to the "list of inconveniences"
> (unless I'm wrong again):
>
> Executable bit is ignored on import
>
> To make files executable, use "svn propset svn:executable on FILE" for
> every executable file. Then run "svn commit" to commit your changes.
> "svn import" doesn't do it automatically yet.
Yes, we've been talking about fixing this bug all day today. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Additions to INSTALL
Posted by Sander Striker <st...@apache.org>.
> From: Pavel Roskin [mailto:proski@gnu.org]
> Sent: 26 September 2002 01:28
>> Well, when you install mod_dav_svn, it calls apxs which should add
>> this line to your config. Therefor the line doesn't have to be
>> added (it's already there).
>
> Ok, it's the result of my paranoya. I made /usr/local/apache2/modules/
> writable by me and ran "make install" as user. I prefer to know which
> directories the installers want to use, rather than give then carte
> blanche to fill /usr/bin with things I may want to uninstall tomorrow.
> On the other hand, I'm behind firewall and don't care about somebody
> escalating permissions from my account to root, at least for now.
>
> Note that "make install" succeeded. Apparently, apxs from Apache 2.0.41
> doesn't consider the failure to open httpd.conf fatal (look for yourself,
> it's a Perl script).
heh. Point taken. Patches always welcome at dev@httpd.apache.org ;)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
> Well, when you install mod_dav_svn, it calls apxs which should add
> this line to your config. Therefor the line doesn't have to be
> added (it's already there).
Ok, it's the result of my paranoya. I made /usr/local/apache2/modules/
writable by me and ran "make install" as user. I prefer to know which
directories the installers want to use, rather than give then carte
blanche to fill /usr/bin with things I may want to uninstall tomorrow.
On the other hand, I'm behind firewall and don't care about somebody
escalating permissions from my account to root, at least for now.
Note that "make install" succeeded. Apparently, apxs from Apache 2.0.41
doesn't consider the failure to open httpd.conf fatal (look for yourself,
it's a Perl script).
[proski@marabou svn-build]$ make install-mods-shared
...
chmod 755 /usr/local/apache2/modules/mod_dav_svn.so
[activating module `dav_svn' in /usr/local/apache2/conf/httpd.conf]
unable to open configuration file
[proski@marabou svn-build]$ echo $?
0
[proski@marabou svn-build]$
> "Make sure that the mod_dav_svn module is loaded when the server
> starts. If the following line is not present in the config
> file, add it as the last one in the section where the other
> LoadModule lines are.
Yes, that would be nice, since installations can be different.
--
Regards,
Pavel Roskin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [PATCH] Additions to INSTALL
Posted by Sander Striker <st...@apache.org>.
> From: Pavel Roskin [mailto:proski@gnu.org]
> Sent: 26 September 2002 00:35
>>> + Add this line after the last LoadModule directive:
>>> +
>>> + LoadModule dav_fs_module modules/mod_dav_fs.so
>>> +
>>
>> Huh? Why would we need the mod_dav_fs backend to mod_dav?
>
> I'm sorry. I meant this line:
>
> LoadModule dav_svn_module modules/mod_dav_svn.so
>
> It doesn't work otherwise:
>
> # service httpd2 start
> Starting httpd2: Syntax error on line 1075 of
> /usr/local/apache2/conf/httpd.conf:
> Unknown DAV provider: svn
>
> I took this line from packages/rpm/subversion.conf in the Subversion
> repository. That's the only file where modules/mod_dav_svn.so is
> mentioned. I would think that INSTALL should have it too.
Well, when you install mod_dav_svn, it calls apxs which should add
this line to your config. Therefor the line doesn't have to be
added (it's already there).
But, for clarity we could put a short paragraph in INSTALL about
it. Something like:
"Make sure that the mod_dav_svn module is loaded when the server
starts. If the following line is not present in the config
file, add it as the last one in the section where the other
LoadModule lines are.
LoadModule dav_svn_module modules/mod_dav_svn.so
"
Ofcourse this can be worded much better... ;)
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Additions to INSTALL
Posted by Pavel Roskin <pr...@gnu.org>.
Hi, Ben!
> > I'm just starting using Subversion, and this patch adds pieces that were
> > not immediately obvious for me when I tried to install the server.
>
> Hey, it's Pavel! Aren't you a famous CVS guy? :-)
Not really famous, but my name can be found in the CVS changelogs (mostly
petty things).
> Glad to see you.
>
> > + Add this line after the last LoadModule directive:
> > +
> > + LoadModule dav_fs_module modules/mod_dav_fs.so
> > +
>
> Huh? Why would we need the mod_dav_fs backend to mod_dav?
I'm sorry. I meant this line:
LoadModule dav_svn_module modules/mod_dav_svn.so
It doesn't work otherwise:
# service httpd2 start
Starting httpd2: Syntax error on line 1075 of
/usr/local/apache2/conf/httpd.conf:
Unknown DAV provider: svn
I took this line from packages/rpm/subversion.conf in the Subversion
repository. That's the only file where modules/mod_dav_svn.so is
mentioned. I would think that INSTALL should have it too.
> > + Initialize the repository. This is described in the README file.
> > +
>
> Um, at the top of section C, we have:
You are right.
> > Fire up apache 2.0:
> >
> > $ /usr/local/apache2/bin/apachectl stop
> > $ /usr/local/apache2/bin/apachectl start
> >
> > + On Red Hat, you might need to use following commands instead:
> > +
> > + $ service httpd2 stop
> > + $ service httpd2 start
>
> Ah, this seems nice... but this whole document assumes you're building
> apache2 from source code, and installing into some prefix. How does
> the redhat 'service' program know where to find your freshly built and
> installed httpd-2.0?
I see. I installed RPM files and then recompiled the latest subversion
only. The RPM files don't include apachectl, and that seem to be an
intentional decision.
Re: [PATCH] Additions to INSTALL
Posted by Ben Collins-Sussman <su...@collab.net>.
Pavel Roskin <pr...@gnu.org> writes:
> Hello!
>
> I'm just starting using Subversion, and this patch adds pieces that were
> not immediately obvious for me when I tried to install the server.
Hey, it's Pavel! Aren't you a famous CVS guy? :-)
Glad to see you.
> + Add this line after the last LoadModule directive:
> +
> + LoadModule dav_fs_module modules/mod_dav_fs.so
> +
Huh? Why would we need the mod_dav_fs backend to mod_dav?
> D. Running and Testing
> -------------------
>
> + Initialize the repository. This is described in the README file.
> +
Um, at the top of section C, we have:
C. Configuring Apache for Subversion
---------------------------------
The following assumes you have already created a repository.
For documentation on how to do that, see README.
Should we also put it in section D?
> Fire up apache 2.0:
>
> $ /usr/local/apache2/bin/apachectl stop
> $ /usr/local/apache2/bin/apachectl start
>
> + On Red Hat, you might need to use following commands instead:
> +
> + $ service httpd2 stop
> + $ service httpd2 start
> +
Ah, this seems nice... but this whole document assumes you're building
apache2 from source code, and installing into some prefix. How does
the redhat 'service' program know where to find your freshly built and
installed httpd-2.0?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org