Stefan Sperling :
> Another useful feature would be built-in support for Git's fast-export
> streams in svnadmin dump/load.
That would be a very good idea. But not easy.
reposurgeon reads and understands Subversion dump files. If you want a running
start of fast import and fast export, look at t
On Mon, Jun 24, 2019 at 04:24:46PM +0200, Branko Čibej wrote:
> 3. "This protocol is too chatty, let's invent a better one"
>
> Our wire protocol is a module. We can invent new ones without affecting
> existing ones. Likewise for repository storage, or working copy storage,
> etc. (with the latter
On 21.06.2019 13:12, Nathan Hartman wrote:
> Subversion 1.x is mature, stable, rock-solid, reliable, and safe. The
> goal of 1.x is now stability and availability. Big changes and
> whiz-bang new features don't really belong there. It's time for
> Subversion 2.0, the Subversion of the future.
I do
An interesting if slightly sad read. I want to add my support and praise
as a long-time user of Subversion.
I still come across many users out there. Subversion is thriving in one
particular business I work with. The youngsters have brought some Git in
with them but it seems to be led by fashi
> [..] How can we leverage Subversion's centralized structure to give
> something _better_than modern workflows?
I'm the guy behind http://trunkbaseddevelopment.com and am predictably
going to say the workflow Svn needs to ace is trunk-based development.
That includes (since 2008) some mechanism f
5 matches
Mail list logo
