On Mon, Jul 26, 2010 at 12:30 PM, Bob Archer wrote:
>> We used to be brutal against adding flags let alone separate
>> binaries,
>> so why are we so willing to add new binaries willy-nilly? To me,
>> as
>> an admin, it just makes *so* much sense that a remote dump feature
>> be
>> tied into "svna
> We used to be brutal against adding flags let alone separate
> binaries,
> so why are we so willing to add new binaries willy-nilly? To me,
> as
> an admin, it just makes *so* much sense that a remote dump feature
> be
> tied into "svnadmin dump". -- justin
I agree this makes sense.
You coul
On Mon, Jul 26, 2010 at 10:09 AM, Ramkumar Ramachandra
wrote:
> +1
>
> I don't see how it's possible to merge, atleast at this
> stage. `svnadmin` is inherently dependent on the filesytem- we should
> be careful not to stuff too much unrelated functionality into one
> tool.
I disagree - I think w
Hi,
David Glasser writes:
> But we do. 'svn' is a wrapper around svn_client/svn_ra. 'svnadmin'
> is a wrapper around svn_repos/svn_fs. 'svn' always refers to
> repositories via URLs. 'svnadmin' always (I think) refers to
> repositories via paths. 'svnadmin' does not have a dependency on Neon
Hi Stefan,
Stefan Sperling writes:
> I am a bit worried that a loader is being worked on before the dumper is
> completely done. I think we should finish the dumper first.
Don't worry about it- I won't leave the dumper pending. It's just that
there are some changes that I'm waiting for before com
On Mon, Jul 26, 2010 at 8:30 AM, Justin Erenkrantz
wrote:
> On Mon, Jul 26, 2010 at 8:10 AM, Hyrum K. Wright
> wrote:
>> +1. The charter for svnadmin is currently, and should remain, solely
>> focused on local access to a repository.
>
> Why?
>
> svnadmin dump --remote
>
> seems the most intuit
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: maandag 26 juli 2010 17:15
> To: Justin Erenkrantz
> Cc: Bert Huijben; Ramkumar Ramachandra; Subversion-dev Mailing List
> Subject: Re: Proposal: Rename svnrdump
>
> On Mon, Jul 26,
On Mon, Jul 26, 2010 at 8:10 AM, Hyrum K. Wright
wrote:
> +1. The charter for svnadmin is currently, and should remain, solely
> focused on local access to a repository.
Why?
svnadmin dump --remote
seems the most intuitive approach for this - as well as load, etc, etc.
We don't differentiate
On Mon, Jul 26, 2010 at 07:54:30AM -0700, Justin Erenkrantz wrote:
> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
> > (A much older suggestion was moving the code into svnsync as they are
> > related tools)
>
> I think either that or folding it into svnadmin itself. But, we don't
> need
On Mon, Jul 26, 2010 at 10:08 AM, C. Michael Pilato wrote:
> On 07/26/2010 10:54 AM, Justin Erenkrantz wrote:
>> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
>>> (A much older suggestion was moving the code into svnsync as they are
>>> related tools)
>>
>> I think either that or folding i
On 07/26/2010 10:54 AM, Justin Erenkrantz wrote:
> On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
>> (A much older suggestion was moving the code into svnsync as they are
>> related tools)
>
> I think either that or folding it into svnadmin itself. But, we don't
> need another tool program
On Mon, Jul 26, 2010 at 6:16 AM, Bert Huijben wrote:
> (A much older suggestion was moving the code into svnsync as they are
> related tools)
I think either that or folding it into svnadmin itself. But, we don't
need another tool program, IMO. -- justin
On Mon, Jul 26, 2010 at 03:16:35PM +0200, Bert Huijben wrote:
> But I'm fine with just keeping 'svnrdump' even for loading. It just uses
> 'dump' for referring that it processes dumpfiles (like svndumpfilter does),
> instead of to just dumping the repository.
+1
Stefan
> -Original Message-
> From: Ramkumar Ramachandra [mailto:artag...@gmail.com]
> Sent: maandag 26 juli 2010 14:13
> To: Subversion-dev Mailing List
> Subject: Proposal: Rename svnrdump
>
> Hi,
>
> I've started working on load support too, and `svnrdump load` can be
> quite misleading- shou
14 matches
Mail list logo
