Re: Will Subversion upgrade from Python 2.x to 3.7.3?
On 02.07.2019 17:47, Smith, Madison (CGI Federal) wrote: > > Good morning SVN Devs! > > > > I've been looking at the roadmap and was wondering why there isn't any > push to move to Python 3? > > > > Python 2 support ends at the end of the year...in 3 months! Many big > businesses, contractors, etc that use this product for years will no > longer be able to as they have policies in place about not using > unsupported software/libraries. > > > > Could we expect a switch to Python 3 and if so is there an ETA? > All our development tools -- build generator, tests etc. -- already work with Python 3. It you're interested in the Python bindings, then please take a look at this branch: https://svn.apache.org/viewvc/subversion/branches/swig-py3/ It's mostly complete but still needs some work before we can merge it to trunk. Any help would be most welcome. -- Brane
Re: Checkpointing
Imagine working on one larger feature (or even multiple features). You already have created a couple of local commits, but are not yet finished. Following use cases come to my mind: 1) some other developer commits new revisions - it should be possible to continue working on your feature-queue keeping it based on the old revision, but sooner or later it comes the time to integrate the new revision(s) - this means to create a new queue on the new revision and cherry-pick all local commits of the old queue onto this new revision (could this be done with purely local information or would each cherry-pick require a possibly slow communication with the server?) - with each cherry-pick, a conflict might occur - aborting should abort the creation of the new queue and application of the old queue, resulting in the deletion of the partly finished new queue keeping the old one - each queue should be rebased independently onto the new revisions 2) you have to make a quick-fix revision - you need to switch from your local feature-queue to the latest revision and fix the bug a coworker requests to get fixed - you may now switch back to your queue to proceed with the work, but there is a new revision now, so you should base your work sooner or later on that revision 3) you want to rework your local commits, e.g. change order, squash some commits, change the message - create a new queue based on the same revision - create new local commits by cherry-picking commits from the other (old) queue, maybe amending some local commits - after the new queue is ready (verify to diff it with the old queue) the old queue can be deleted - often enough I find it useful to be able to make one of my first feature commits public, so the x first local commits should be possible to be become revisions => the queue becomes shorter and based on the new revision(s) 4) you need to fork an existing queue at any local commit - switching to one of the local commits of your current queue you detect that it contains a flaw - creating now a local commit to fix would mean to first create a new queue based on the same revision, apply all previous local commits (no conflict risk) - the old queue would be kept It might be useful to be able to "store" somehow one or another queue on the server, e.g. for backup reasons, so no change is lost if my hard disk crashes or my code fails and cleans the disk. (Creating a new, real feature branch with revisions in the repository I don't like because then they would be cut in stone and this would force me to create nice and clean commits. But because we are not without error, such code will contain back and forth changes and hence hard to read.) As long as I'm working on a non-trivial feature/refactoring, I prefer to have complete control over my commits, I even like to commit completely unstable and incomplete code with Git - because I have the possibility to clean up later. -- Best regards, Thomas Singer On 02/07/2019 18:32, Nathan Hartman wrote: On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer wrote: With "rebasing" I mean, that such list of "local commits" needs to be re-applied (on demand, not automatically) onto a different revision. Something like a continues series of cherry-picking (with the possibility to get a conflict in each step; and a possibility to continue after conflict resolution or abort). This means to me, that at least cherry-picking needs to be possible from a revision or a "local commit". Could you describe how you would like to use this capability? E.g., give an example use case?
Re: Subversion 2.0
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 "simple" > tasks, and even the available GUIs are not always helpful. HG is doing a > much better job here, as far as I can see... > > It stand and falls with the user interface. > > And we should take it seriously from the beginning. When the new features > are implemented with unusable/complex UI first, users will want to try it, > fail, and turn away. We won't be able to catch them later when the UI is > better... I agree. A bad user interface will result in complaints that repeat around the Internet in perpetuity, even after the problems are fixed. I think we know this from experience! Also, once the interface gets "grandfathered in," it can't / won't change because of compatibility. I'm studying this issue and I'll be back with some concrete suggestions; in the meantime I'd love to hear your thoughts as well! Especially use cases. :-)
Re: Checkpointing
On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer wrote: > With "rebasing" I mean, that such list of "local commits" needs to be > re-applied (on demand, not automatically) onto a different revision. > Something like a continues series of cherry-picking (with the > possibility to get a conflict in each step; and a possibility to > continue after conflict resolution or abort). This means to me, that at > least cherry-picking needs to be possible from a revision or a "local > commit". > Could you describe how you would like to use this capability? E.g., give an example use case?
Will Subversion upgrade from Python 2.x to 3.7.3?
Good morning SVN Devs! I've been looking at the roadmap and was wondering why there isn't any push to move to Python 3? Python 2 support ends at the end of the year...in 3 months! Many big businesses, contractors, etc that use this product for years will no longer be able to as they have policies in place about not using unsupported software/libraries. Could we expect a switch to Python 3 and if so is there an ETA? Thank you, Madison J. Smith Proprietary/confidential information belonging to CGI Federal Inc. or its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for the delivery of this message to such person), or if you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply email.
Successful build on 32-bit ARM
I finally got one step further on my ARM build slave project. This is a Raspberry Pi 4 B with 2 gigs of RAM: sysop@pihole:~ $ uname -a Linux pihole 4.19.50-v7l+ #895 SMP Thu Jun 20 15:03:42 CET 2019 armv7l GNU/Linux sysop@pihole:~ $ lsb_release -a No LSB modules are available. Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster The maintainer-mode build produced only a couple of warnings that are worth following up, local tests and all bindings tests work, I'm running svnserve and DAV tests now (with a RAMdisk, no less). -- Brane sysop@pihole:~ $ ./src/svn/build/subversion/svn/svn --version svn, version 1.13.0-dev (under development) compiled Jul 2 2019, 10:00:31 on armv7l-unknown-linux-gnueabihf Copyright (C) 2019 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.9 (compiled with 1.3.9) - handles 'http' scheme - handles 'https' scheme The following authentication credential caches are available: * GPG-Agent
