On 29.07.2019 11:36, 钱海远(Nathan) wrote:
>
> Dear Develop Team,
>
>
>
> We have created a system for pre-commit review in our company (Force
> Review, or pre-commit hooks will reject commit), as shown below.
>
>
>
> But SVN does not support staging code area.
>
There's nothing wrong with using
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
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
On Sun, Jun 30, 2019 at 4:47 AM Greg Stein wrote:
> On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman
> wrote:
>
>> 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 y
On Tue, Jun 25, 2019 at 6:18 PM Nathan Hartman
wrote:
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej wrote:
> >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 onl
> 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
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
>
> On Tue, Jun 25, 2019 at 5:34 PM Branko Čibej wrote:
>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
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 Subversion of the future.
I do
> [..] 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
On Fri, Jun 21, 2019 at 10:38 AM Mark Phippard wrote:
> I think the reason that both Subversion and Git were successful is that
> they both had very clear and compelling visions and goals for what they
> wanted to accomplish and then they did that.
>
> I do not think a few new features or design
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 going
> to write what. Ri
21 matches
Mail list logo
