Ramkumar Ramachandra wrote on Fri, Aug 20, 2010 at 10:29:15 +0530:
> Hi Jon,
>
> Jon Foster writes:
> > Daniel Shahaf wrote:
> > > Yes:
> > >
> > > svn propset --revprop svn:author
> > > svn propset --revprop svn:date
> > >
> >
> > But not by default. Changing revprops has to be explicitly ena
Itamar O wrote on Fri, Aug 20, 2010 at 00:05:37 +0300:
> Is this command going to be supported in the default installation from now?
> or is it a "stand-alone" utility that installs separately?
> In case of the former - will there be a 1.6.13 release that will include it?
> In case of the latter -
Hi Stefan,
Stefan Sperling writes:
> > > Remote "load" seems scary -- How can I prevent my users from being
> > able to use this command? Is the original
> > > author of the dumped
> > revision preserved, or is the author set to the user doing the load?
> > Can users do
> > > anything else bad, l
Hi Jon,
Jon Foster writes:
> Daniel Shahaf wrote:
> > Yes:
> >
> > svn propset --revprop svn:author
> > svn propset --revprop svn:date
> >
>
> But not by default. Changing revprops has to be explicitly enabled by
> the repository administrator. To do this, the server admin has to
> explicitly
Hi Itamar,
Itamar O writes:
> This is exactly a tool I need!
We're glad you like it :)
> I wonder if the dev team has mind-reading abilities...
Hehe, I suppose it helps to think of it that way ;)
In reality, I developed a major part of svnrdump outside the tree, and
merged it into the tree whe
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 19 augustus 2010 13:30
> To: Ramkumar Ramachandra
> Cc: users@subversion.apache.org
> Subject: Re: [ANNOUNCE] svnrdump: A new dumper/ loader in trunk
>
> On Thu, Aug 19,
On Wed, Aug 18, 2010 at 9:50 PM, Ramkumar Ramachandra wrote:
> Hi,
>
> There's now a new tool located in subversion/svnrdump. We have
> developed it over the last few weeks, and we feel that it is mature
> enough to announce. Although it has not been tested extensively, we
> would like to encourag
Daniel Shahaf wrote:
> Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 15:27:25 -0500:
> > Ramkumar:
> > > Again, I expect that access control/ security is automatically
taken care
> > > of in the RA layer. `svnrdump load` is just like a user making
some changes
> > > and committing them one by o
Les Mikesell wrote on Thu, Aug 19, 2010 at 15:25:51 -0500:
> On 8/19/2010 3:13 PM, Daniel Shahaf wrote:
>> Let me say that even more clearly: svnrdump is a new CLIENT-SIDE tool.
>> It did not change a millimeter in the server code or in the network
>> protocols. That severly limits the extent of s
Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 15:27:25 -0500:
> Ramkumar:
> > Again, I expect that access control/ security is automatically taken care
> > of in the RA layer. `svnrdump load` is just like a user making some changes
> > and committing them one by one except the author and timest
On Thu, Aug 19, 2010 at 08:02:02PM +, Ramkumar Ramachandra wrote:
> Feldhacker, Chris principal.com> writes:
> > Remote "dump" makes sense -- and I assume everything being dumped is
> subject to the authorization/access
> > control restrictions that have
> been put into place on the server, ye
Ramkumar:
> Again, I expect that access control/ security is automatically taken care
> of in the RA layer. `svnrdump load` is just like a user making some changes
> and committing them one by one except the author and timestamp in the
> dumpfile are preserved. Why would you want to block this?
On 8/19/2010 3:13 PM, Daniel Shahaf wrote:
Let me say that even more clearly: svnrdump is a new CLIENT-SIDE tool.
It did not change a millimeter in the server code or in the network
protocols. That severly limits the extent of security issues it can
introduce.
I guess it would be the equivalen
Let me say that even more clearly: svnrdump is a new CLIENT-SIDE tool.
It did not change a millimeter in the server code or in the network
protocols. That severly limits the extent of security issues it can
introduce.
Feldhacker, Chris wrote on Thu, Aug 19, 2010 at 14:14:30 -0500:
> Any "rough" d
Feldhacker, Chris principal.com> writes:
> Remote "dump" makes sense -- and I assume everything being dumped is
subject to the authorization/access
> control restrictions that have
been put into place on the server, yes? (A particular path or file
won't be
> included in the dump if the user doesn
Any "rough" documentation available, particularly in terms of security or
access control?
Remote "dump" makes sense -- and I assume everything being dumped is subject to
the authorization/access control restrictions that have been put into place on
the server, yes? (A particular path or file w
16 matches
Mail list logo
