On Mon, Jul 26, 2010 at 10:09 AM, Ramkumar Ramachandra
<artagnon_at_gmail.com> 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 we already have far many "tools" and we need to
consolidate them down. It's confusing to say, "oh, you need svnadmin
for this, svnsync for that, svnmucc for that" and now you need
"svnrdump" for that. Ugh. I really think it would benefit everyone
(especially administrators) if we could simplify our administration
story - we've let it get way too confusing.
Almost everything client-facing - at the CLI level - is in sitting in
the "svn" binary - why shouldn't it all be the same for our admins?
Why must we add yet another tool? svnadmin can certainly learn more
commands, so I buy the technical arguments as a dodge. Right now,
svnadmin just takes local paths - but this feature starts to let you
do administrative things remotely - so we're letting our previous
functional limitations affect what is intuitive, IMO.
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
Received on 2010-07-26 19:22:08 CEST