e to http://192.168.0.3:907/svn with a browser?
Cheers,
--
Johan
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5761 (20110105) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
On Tue, 2011-01-04 at 17:29 -0800, Blair Zajac wrote:
> On 12/25/10 5:42 PM, Kenneth Russell wrote:
> > Hello,
> >
> > The WebKit project uses Subversion for version control and we are
> > facing a problem with fresh checkouts of the repository on Windows
> > with Subversion 1.6.6 (as well as earli
On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell wrote:
> Of course you _can_ secure it. My point is that permitting ssh and
> restricting access to ssh by itself is very likely to make your system less
> secure (if you count on firewall protections) instead of more so. And
> nothing that can be don
See this thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377143
Realistically today you need to add a pre-lock hook on the slave that
disallows the lock feature entirely.
Mark
On Wed, Jan 5, 2011 at 6:07 PM, Edward Ned Harvey wrote:
> I have a master server,
I have a master server, and a slave server configured with pass-thru proxy.
Off the top of my head, I believe they're both 1.6.12, but I'll double check
if that is an important detail.
A user at the slave site does "get lock" on a file. She gets the lock
successfully.
She makes a change, trie
On Wed, Jan 5, 2011 at 5:03 PM, wrote:
> Dave, if you look into how the hooks work, basically, they are passed a
> repo path and a transaction id that, using svnlook, gives you access to
> copies of the working files, so it doesn't matter where the hooks run, nor
> is there any requirement for se
On Wed, Jan 5, 2011 at 17:03, wrote:
> Dave, if you look into how the hooks work, basically, they are passed a repo
> path and a transaction id that, using svnlook, gives you access to copies of
> the working files, so it doesn't matter where the hooks run, nor is there
> any requirement for serv
Dave, if you look into how the hooks work, basically, they are passed a repo
path and a transaction id that, using svnlook, gives you access to copies of
the working files, so it doesn't matter where the hooks run, nor is there any
requirement for server/client communication.
Though I do love i
Interesting. These look like directory names. The ones that start with "?"
are not under Subversion control. Are these the ones you moved? The directoy
is "src/main/java/...", so I assume these should be under version control.
Did you move your directories around?
The strange thing is the "~" mark
On Wed, Jan 5, 2011 at 11:30 AM, wrote:
> I'm working on porting a fairly extensive set of CVS hooks to SVN.
Okay. Stop right there. When ever someone mentions "a fairly extensive set"
of hooks, I start to think maybe most of what they want shouldn't
necessarily be hooks. When hooks are running
On 1/5/2011 1:04 PM, David Brodbeck wrote:
It's possible to do secure Subversion. Use svn+ssh access,
disable or
block other services at the firewall,
If ssh is permitted and you didn't personally set it up, what are
the odds that port tunneling or ssh's built i
On Mon, Jan 3, 2011 at 8:46 AM, Les Mikesell wrote:
> On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>
>>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall,
>>
>
> If ssh is permitted and you didn't personally set it up, what are the o
On Tue, Jan 4, 2011 at 6:31 PM, Nico Kadel-Garcia wrote:
> It's *too* easy. Since the default svnserve.conf is very permissive,
> and because default svnserve is on an unprivileged port so any user
> can serve anyone else's "readable" repository to outside access,
> without the original author's
I'm working on porting a fairly extensive set of CVS hooks to SVN. The issue
that I'm having now is that my pre-commit hook, which runs a Perl script that
performs tests based on Test::Builder and Test::More, never show their stderr
on the console. I see it in the svn web server logs, but not
On Wed, Jan 5, 2011 at 3:18 PM, zhangfan wrote:
> Hi All
>
> I am using svn1.6.3. I put all source code and documents of our
> team into one repo. It works great for two years until last month. Now when
> I run ‘svn log http://192.168.0.3:907/svn’ (where 192.168.0.3 is our
> server’s addr
Thanks a lot David!
This is the output to my status command:
iapm270...@uioiapm270409:~/workspace/intranet/recursos-revision$ svn
status
M .
~ recursos-revision-ejb/target
?
recursos-revision-ejb/src/main/java/ec/gob/sri/recursos/revision/comun
?
recursos-revision-ejb/src/main/java/ec
Hi All
I am using svn1.6.3. I put all source code and documents of our
team into one repo. It works great for two years until last month. Now when
I run 'svn log http://192.168.0.3:907/svn' (where 192.168.0.3 is our
server's address), svn returns 'svn: REPORT request failed on
'/svn/!svn/
Nico, please stop saying "I don't like X" everywhere.
Stefan Sperling wrote on Wed, Jan 05, 2011 at 11:09:06 +0100:
> On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> > This is a very large and longstanding issue for me and others, and has
> > led to clients of mine rejecting S
Daniel Shahaf daniel.shahaf.name> writes:
>> No file matching '*.foo' - to expand wildcards, say
>> svn commit --changelist :glob:'*.foo'
>
>This can't be implemented in svn itself: for example, my shell
>simply raises an error (without running the program) if a wildcard
>failed to match
Nice, please stop saying "I don't like X" everywhere.
Stefan Sperling wrote on Wed, Jan 05, 2011 at 11:09:06 +0100:
> On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> > This is a very large and longstanding issue for me and others, and has
> > led to clients of mine rejecting S
Ed Avis wrote on Wed, Jan 05, 2011 at 12:52:39 +:
> Daniel Shahaf daniel.shahaf.name> writes:
>
> > svn commit --changelist :glob:'*.foo'
>
> From my point of view that would be useful, if combined with a warning
> message:
>
>No file matching '*.foo' - to expand wildcards, say
>
Daniel Shahaf daniel.shahaf.name> writes:
> svn commit --changelist :glob:'*.foo'
>From my point of view that would be useful, if combined with a warning message:
No file matching '*.foo' - to expand wildcards, say
svn commit --changelist :glob:'*.foo'
Thanks for producing the patch -
On Tue, Jan 04, 2011 at 09:25:11PM -0500, Nico Kadel-Garcia wrote:
> This is a very large and longstanding issue for me and others, and has
> led to clients of mine rejecting Subversion outright. And it looks
> like a legacy of Subversion's re-implementation of CVS, described as
> "CVS done right".
On Tue, Jan 04, 2011 at 09:20:52PM -0500, Nico Kadel-Garcia wrote:
> On Tue, Jan 4, 2011 at 6:35 PM, NN Ott wrote:
> > Hello,
> >
> > I have a source library that I need to periodically import (and then patch)
> > for use by my code base.
> >
> > The SVN Book seems to reccomend a "vendor branch" s
24 matches
Mail list logo
