doubt that you really need support from core Subversion
for this. If you can implement master/master replication, surely you can
also implement some kind of "pre" commit review workflow. You don't need
Subversion 2.0 for that.
-- Brane
The "shelve" functionality in Subversion may be grown into a "continuous
review" system in the future. If you can't wait that long Rhodecode and
Assembla both give Subversion a code review capability today and would be
able to migrate your existing repo to their tech/service. Various CollabNet
prod
tion) by persons other than the intended recipient(s) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email
immediately and delete it!
发件人: Nathan Hartman
发送时间: 2019年7月3日 0:41
收件人: Markus Schaber
抄送: Thomas Singer ; Subversion Developers
主题: Re: Subver
On Fri, Jun 28, 2019 at 12:51 PM Markus Schaber
wrote:
> It's a very powerful feature, on par or even superior to other (D)VCSes -
> as long as we manage to keep the interface clear enough that users can
> handle everything.
>
> I'm always astonished how complicated GIT can be for seemingly "simp
g to be broken. A 2.0 means you can break those promises, BUT I propose
>> that just because you CAN do something doesn't mean you have to. Subversion
>> 2.0 could very well keep 100% of 1.x's promises.
>>
>
> That isn't how it works.
>
> Subversion 1.
are
> going to be broken. A 2.0 means you can break those promises, BUT I propose
> that just because you CAN do something doesn't mean you have to. Subversion
> 2.0 could very well keep 100% of 1.x's promises.
>
That isn't how it works.
Subversion 1.x is a signal t
Hi, Nathan,
Von: Nathan Hartman
> Let's put our "future caps" on...
> Imagine a fully-functioning checkpointing feature:
[...]
> How does the future look so far? :-)
Looks very bright for me! :-)
It's a very powerful feature, on par or even superior to other (D)VCSes - as
long as we manage
> On Jun 28, 2019, at 12:29 PM, Nathan Hartman wrote:
>
>> On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer
>> wrote:
>
>> What I like most about Git:
>> - it allows to create clean commits, because I can modify all my local
>> commits, e.g. reorder and squash them, in case I detected an error i
On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer
wrote:
> What I like most about Git:
>
- it allows to create clean commits, because I can modify all my local
> commits, e.g. reorder and squash them, in case I detected an error in a
> previous, unpushed commit
>
> - I can solve every conflict loca
Hi Branko,
Thanks for the detailed explanation. Would you mind to add the
description to the linked issue and mark it as
resolved/works-for-me/no-bug, so this information is not lost?
--
Best regards,
Thomas Singer
=
syntevo GmbH
On 26/06/2019 17:39, Branko Čibej wrote:
On 26.0
On 26.06.2019 10:40, Marc Strapetz wrote:
> On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
> Singer wrote:
>>> What I don't like:
>>> - after more than a decade the umlaut problem of composed/decomposed
>>> UTF-8 has not been solved
>>
>> It has, actually, in Apple's APFS, wh
On 25.06.2019 23:35, Branko Čibej wrote:> On 25.06.2019 19:15, Thomas
Singer wrote:
What I don't like:
- after more than a decade the umlaut problem of composed/decomposed
UTF-8 has not been solved
It has, actually, in Apple's APFS, where the fix belongs.
That sounds interesting. Just to be s
in addition to plans
for a 2.0.
I understand that from a technical perspective, there is no reason to
change the major version number unless compatibility/API/ABI promises are
going to be broken. A 2.0 means you can break those promises, BUT I propose
that just because you CAN do something does
On 25.06.2019 19:15, Thomas Singer wrote:
> What I don't like:
> - after more than a decade the umlaut problem of composed/decomposed
> UTF-8 has not been solved
It has, actually, in Apple's APFS, where the fix belongs.
-- Brane
On 25.06.2019 19:16, Thomas Singer wrote:
>> I don't want to rain on anyone's parade but here's some food for
>> thought. The only valid reason to call anything 2.0 is if, and only if,
>> we decide to break backwards compatibility in some area.
>
> I disagree. It is quite common use to name somethi
I don't want to rain on anyone's parade but here's some food for
thought. The only valid reason to call anything 2.0 is if, and only if,
we decide to break backwards compatibility in some area.
I disagree. It is quite common use to name something 2.0 if it has
serious improvements over 1.x.
-
What I like with SVN:
- it is easy to fix commit messages
- the externals are easy to understand
- the properties
- the file locking
What I don't like:
- after more than a decade the umlaut problem of composed/decomposed
UTF-8 has not been solved
What I like most about Git:
- it allows to crea
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 Subver
> [..] 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
Hi,
> The future isn't written yet. It can be anything. And since this is the idea
> phase of Subversion 2.0, there's no need to worry about specifics, like how
> to solve particular coding problems or who specifically is going to write
> what. Right now is the time to dr
;
I'm glad you brought that up because it's exactly what I want to
address today.
One of my goals for Subversion 2.0 is to attract new users and
developers to the project.
The obvious question is: How?
Git is the 800 pound gorilla in the version control room, so any
strategy to
On 21.06.2019 17:05, Paul Hammant wrote:
>> building those ideas on the Subversion 1.x code base
> +1
>
>> Rust or Go
> +1. Rust doesn't yet target all the platforms that Subversion already
> targets. It will do though, there's something unstoppable about the
> Rust community. I commissioned Rust p
> building those ideas on the Subversion 1.x code base
+1
> Rust or Go
+1. Rust doesn't yet target all the platforms that Subversion already
targets. It will do though, there's something unstoppable about the
Rust community. I commissioned Rust ports of Python pieces on UpWorks
for fixed prices
On Fri, Jun 21, 2019 at 7:13 AM Nathan Hartman
wrote:
> The future isn't written yet. It can be anything. And since this is the
> idea phase of Subversion 2.0, there's no need to worry about specifics,
> like how to solve particular coding problems or who specifically is go
e has been many years of use,
ZERO problems, and Subversion's enterprise features are a big win.
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'
27 matches
Mail list logo
