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 nonot...@gmail.com 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
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. CVS
Daniel Shahaf d.s at 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
Ed Avis wrote on Wed, Jan 05, 2011 at 12:52:39 +:
Daniel Shahaf d.s at 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
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
Daniel Shahaf d.s at 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
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
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
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
?
On Wed, Jan 5, 2011 at 3:18 PM, zhangfan zhang...@siit-cn.com 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
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 Tue, Jan 4, 2011 at 6:31 PM, Nico Kadel-Garcia nka...@gmail.com 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
On Mon, Jan 3, 2011 at 8:46 AM, Les Mikesell lesmikes...@gmail.com 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
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
On Wed, Jan 5, 2011 at 11:30 AM, eric.b...@barclayscapital.com 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
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 17:03, eric.b...@barclayscapital.com 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
On Wed, Jan 5, 2011 at 5:03 PM, eric.b...@barclayscapital.com 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
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, tries
See this thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462dsMessageId=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 s...@nedharvey.com wrote:
I have
On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell lesmikes...@gmail.com 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
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 earlier
,
--
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
23 matches
Mail list logo
