Re: Subversion 2.0
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 uncommitted transaction as the "staging code area," although the command-line client will probably try to remove it after it times out, so you'd have to integrate the code review logic with the client somehow. Or you could use temporary branches: the code review logic could create a commit on a temporary branch from the commit transaction, then reject the commit. Once approved, the temporary branch would be merged back to the original commit target. Or you could save the transaction itself and then replay it locally. In any case I 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
Re: Subversion 2.0
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 products may do so too. - Paul
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: Subversion 2.0
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 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 to system administrators that they can upgrade > their 1.x installations to the latest 1.x and NOT WORRY. > > Once you bring in 2.x, regardless of what the developers do to keep/lose > compatibility ... you have lost the 20-year guarantee of compatibility. The > admin must now do some research. And the question in that admin's head will > always be "what am I missing? if this is compatible with 1.x, and I should > not fear upgrading to 2.0 ... then why did they change the version number? > that was supposed to be a signal." > > For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes > no guarantee". You speak of "marketing". There is no amount of marketing > that will alter the past 20 years of our API guarantees. > > That is actually perfect. There are several challenges here that need to be addressed. One is the need for more developer participation. Working on that... Another is that one of Subversion's strengths is also a weakness. The 20 year guarantee is great for system administrators and users. It demonstrates stability and reliability, which is important given what Subversion does. This isn't a video game; this software houses your precious data! Years and years of forward and backward compatibility is a bragging point and a strength. But it's also a weakness because it means that we can't be bold and experiment, as that would break guarantees and bring instability. So, okay, that's a legitimate explanation as to why we don't up the version number to 2.0 unnecessarily. But I still think we need the *concept* of a 2.0 as a way of moving forward. So I'll alter what I said before, slightly: Bug fixes, stability improvements, and stable production-ready features should go into 1.x, while 2.0 should be the playground for bold experiments, developers, and adventurous users. It doesn't matter if there's ever a 2.0 release. Instead, as features in 2.0 become stable and production-ready, they can be merged back to 1.x and become part of the next "no worries" 1.x release, provided they do not break compatibility! If they break compatibility, then we'll cross that bridge when we get to it. So, yes, 1.x can live on and on, until 1.414213562373095. For marketing purposes, we could give names to releases that introduce major new (but stable and production-ready) functionality. The important thing is: We want devs! So we do not want to create an impression that bold new stuff isn't welcome. It's welcome and it has a place called 2.0!!
Re: Subversion 2.0
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 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. > > > >That's marketing, not software development. :) > > Subversion needs some marketing -- separately from and 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 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 to system administrators that they can upgrade their 1.x installations to the latest 1.x and NOT WORRY. Once you bring in 2.x, regardless of what the developers do to keep/lose compatibility ... you have lost the 20-year guarantee of compatibility. The admin must now do some research. And the question in that admin's head will always be "what am I missing? if this is compatible with 1.x, and I should not fear upgrading to 2.0 ... then why did they change the version number? that was supposed to be a signal." For 20 years, the promise has been "upgrade to 1.x without fear. 2.x makes no guarantee". You speak of "marketing". There is no amount of marketing that will alter the past 20 years of our API guarantees. Cheers, -g
Re: Subversion 2.0
> 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 in a >> previous, unpushed commit > >> - I can solve every conflict locally, try again and again, without >> losing any changes (imagine a complicated merge in SVN where you now >> have solved a couple of conflicts, but an update brings new conflicts) > >> - Git allows me to create a feature in my own branch, turn all my >> commits in this branch up-side-down if I need (even after pushing to the >> repository) and finally rebase it on top of the main development branch > > Let's put our "future caps" on... > > Imagine a fully-functioning checkpointing feature: > > Checkpointing is a "local commit history" mechanism, but we don't call > it a "commit" because "commit" is a strong concept in Subversion. > Commit history is immutable: Whatever is committed is safe forever. > > A checkpoint is a weak concept, more like the weak commit history you > find in a DVCS. Checkpoints are local and private until committed or > shared. > > A checkpoint can represent any committable changes. Checkpoints can be > rewritten, modified, reordered, copied, moved, squashed, divided, > deleted, etc. Their commit messages can be edited easily. > > Checkpoints live in arrays of checkpoints. Each array has a user- > assigned descriptive name and serves as a mutable linear mini-history. > Arrays can be copied, renamed, deleted... You can have as many arrays > as you like. > > Checkpoints and arrays of checkpoints can be created and manipulated > by the system or the user. > > By the System: > > Automatic checkpoint before potentially destructive operation: If > there are uncommitted changes in the WC, svn update and svn merge > automatically create a checkpoint. That way, the user never loses a > good working state to a bad one if the update, merge, or ensuing > conflict resolution get messed up (by either the system or user). > You can try again and again until you get it right. > > Automatic checkpoint at specified time intervals: This one is more > applicable to GUI clients. You can tell it to make an automatic > checkpoint, say, every 15 minutes, if there are new changes. Better > yet, the GUI client could monitor the directory / get OS change > notifications and make an automatic checkpoint of every change. So > when you hit "save" in your editor, Subversion makes a checkpoint as > well. Automatically. > > By the User: > > Reordering/rewriting/manipulating means you can work happily and make > checkpoints along the way, ending up with a "messy" checkpoint > history. You can rewrite/reorder checkpoints in place. Or, if you like > "non-destructive editing," create a new separate array and cherrypick > checkpoints onto it, making any edits. If you worked on different > unrelated things, create different unrelated arrays and cherrypick > each checkpoint onto the appropriate array. Once you've built up a > clean linear history of related changes in a checkpoint array, that > array can either be squashed and committed as one commit or left > intact and committed as a sequence of commits. GUI clients could > utilize Subversion's lock-modify-unlock feature to make the separate > commits in order without other unrelated commits getting in the > middle. In the future, a new improved client/server protocol will > support committing an array of checkpoints as a sequence of commits, > atomically. So either all the checkpoints go in or none go in, and > nothing gets in the middle. > > Pull requests: A mechanism to pack up an array of checkpoints in a > single file for sharing with colleagues. No big paragraph needed to > explain this one. > > How does the future look so far? :-) I'd maybe welcome the feature but it wouldn't change much for me as this was never an area of SVN where I felt much pain. For me the problem would be that this is all still built upon a base that does not handle merging or moved files very well. Problems that would mean this feature would also likely suffer from those weaknesses when trying to reconcile your local checkpoints with what has happened upstream as you are pulling in updates. While I can see how this could also aid in the code review options, I think the fact that the Git model is based on reviewing actual commits is still superior because the commit you review is the one that you know is merged/accepted. For this feature it is still just a form or reviewing a patch and there is no real way to verify that what you reviewed is what was merged. At minimum, those are problems that would still need to be solved to claim we are nearing parity with what Git can offer here. More importantly, I still think this is a question that is bigger than features. For the community to
Re: Subversion 2.0
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 locally, try again and again, without > losing any changes (imagine a complicated merge in SVN where you now > have solved a couple of conflicts, but an update brings new conflicts) > > - Git allows me to create a feature in my own branch, turn all my > commits in this branch up-side-down if I need (even after pushing to the > repository) and finally rebase it on top of the main development branch > Let's put our "future caps" on... Imagine a fully-functioning checkpointing feature: Checkpointing is a "local commit history" mechanism, but we don't call it a "commit" because "commit" is a strong concept in Subversion. Commit history is immutable: Whatever is committed is safe forever. A checkpoint is a weak concept, more like the weak commit history you find in a DVCS. Checkpoints are local and private until committed or shared. A checkpoint can represent any committable changes. Checkpoints can be rewritten, modified, reordered, copied, moved, squashed, divided, deleted, etc. Their commit messages can be edited easily. Checkpoints live in arrays of checkpoints. Each array has a user- assigned descriptive name and serves as a mutable linear mini-history. Arrays can be copied, renamed, deleted... You can have as many arrays as you like. Checkpoints and arrays of checkpoints can be created and manipulated by the system or the user. By the System: Automatic checkpoint before potentially destructive operation: If there are uncommitted changes in the WC, svn update and svn merge automatically create a checkpoint. That way, the user never loses a good working state to a bad one if the update, merge, or ensuing conflict resolution get messed up (by either the system or user). You can try again and again until you get it right. Automatic checkpoint at specified time intervals: This one is more applicable to GUI clients. You can tell it to make an automatic checkpoint, say, every 15 minutes, if there are new changes. Better yet, the GUI client could monitor the directory / get OS change notifications and make an automatic checkpoint of every change. So when you hit "save" in your editor, Subversion makes a checkpoint as well. Automatically. By the User: Reordering/rewriting/manipulating means you can work happily and make checkpoints along the way, ending up with a "messy" checkpoint history. You can rewrite/reorder checkpoints in place. Or, if you like "non-destructive editing," create a new separate array and cherrypick checkpoints onto it, making any edits. If you worked on different unrelated things, create different unrelated arrays and cherrypick each checkpoint onto the appropriate array. Once you've built up a clean linear history of related changes in a checkpoint array, that array can either be squashed and committed as one commit or left intact and committed as a sequence of commits. GUI clients could utilize Subversion's lock-modify-unlock feature to make the separate commits in order without other unrelated commits getting in the middle. In the future, a new improved client/server protocol will support committing an array of checkpoints as a sequence of commits, atomically. So either all the checkpoints go in or none go in, and nothing gets in the middle. Pull requests: A mechanism to pack up an array of checkpoints in a single file for sharing with colleagues. No big paragraph needed to explain this one. How does the future look so far? :-)
Re: Subversion 2.0
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 sure, you are referring to this problem: https://issues.apache.org/jira/browse/SVN-2464 ? It would be great to have some more information for which OSX version and which file systems the problem should be resolved. -Marc 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. -- Brane
Re: Subversion 2.0
> > 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 area. >> >> I disagree. It is quite common use to name something 2.0 if it has >> serious improvements over 1.x. > >That's marketing, not software development. :) Subversion needs some marketing -- separately from and 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 doesn't mean you have to. Subversion 2.0 could very well keep 100% of 1.x's promises. Even though the option to break promises exists, I would err on the side of keeping them anyway, unless doing so (very sparingly) would provide compelling benefits that outweigh the hassle caused by such breakage. So why 2.0 then? (1) To separate between a stable 1.x that focuses on keeping a clean issue tracker and a 2.0 that focuses on new and experimental development. This might give more freedom to experiment while reducing risk of disruption to existing customers until new features are release-quality. (2) To make it clear, in light of 1.x "going stable," that the project won't turn away new development or new developers. Both are encouraged and invited with open arms, always. (3) Marketing. Just to make this clear, I do not think it's a good idea to reimplement Subversion in another language and I do not think the nature of Subversion should be changed drastically. That would be a different product. I'm in favor of longevity: Longevity of the project, longevity of keeping promises, backward/forward compatibility between server/client and on-disk data structures, etc. The fact that a dump and load has NOT been needed in many years, the fact that Subversion is careful about preserving your history -- in short, Longevity, should be a bragging point of Subversion. Somewhere you said that it took 4 years to get from nothing to 1.0. The difference between today and back then is that today you have a rock solid, reliable, excellent 1.x; back then you had CVS. There's no rush to release 2.0, or even write code for it. The journey of 1000 miles doesn't begin with a single step; it begins with deciding where to go. :-)
Re: Subversion 2.0
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
Re: Subversion 2.0
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 something 2.0 if it has > serious improvements over 1.x. That's marketing, not software development. :) -- Brane
Re: Subversion 2.0
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. -- Best regards, Thomas Singer = syntevo GmbH
Re: Subversion 2.0
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 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 - it is still much stronger merging renamed, modified files - I can solve every conflict locally, try again and again, without losing any changes (imagine a complicated merge in SVN where you now have solved a couple of conflicts, but an update brings new conflicts) - I can switch branches very quickly back and forth without the need to transfer the whole project over a network (even having to wait a couple of minutes with a decent connection is too slow if you are used to Git's seconds - we are not talking about the fact that it is wasted energy to transfer the same data again and again just because SVN does not cache it) - Git allows me to create a feature in my own branch, turn all my commits in this branch up-side-down if I need (even after pushing to the repository) and finally rebase it on top of the main development branch Of course, the latter only works fine if there is just one developer of this feature branch, but usually this is the case for me. More than 5 years ago we have massively refactored our products to switch from one GUI library to another (Swing -> SWT). Without Git and rebasing this would have been much more complicated. Most of the things I like in Git are not possible with other DVCS, or require some non-standard extensions, or may produce weird states you don't know how to get out. I don't know what SVN 2 would need to have, so I would consider to use it for a software product repository again. -- Best regards, Thomas Singer = syntevo GmbH
Re: Subversion 2.0
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 that code. If somebody on the ore team takes on the job I am willing to help. Success would take a pretty large maintainence burden off me and. yes, it really should live in svndump. I can supply a bunch of useful end-to-end tests of this capability. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Subversion 2.0
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 actually being the hardest to change, due to > hysterical ... um, I mean historical reasons). > Case in point: The ra-git branch started out as a repository access module, and later evolved into a repository fliesystem backend. Our design is flexible enough to allow for such features to be added. Even something like 'Git-backed SVN' would not require a 2.x branch. I would encourage new developers who want to work towards SVN 2.0 to gain some experience by finishing the ra-git branch and making a new 1.x release with built-in Git compatibility. This would go a long way towards allowing users to benefit from the advantages of both SVN and Git. Many environments run a mix of SVN and Git today and SVN will hopefully stay relevant for a longer period of time if it co-operates. Another useful feature would be built-in support for Git's fast-export streams in svnadmin dump/load. Git already has a reasonable level of SVN compatibility on their side. Such compatibility being a one-way street is not nice for users of either tool.
Re: Subversion 2.0
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 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. Now sure we can find more or less valid arguments to do that, but they have to be weighed very carefully indeed. Remember that there's almost 20 years worth of stable code and tests here; you don't throw that away without due consideration. We should also keep in mind the many, many existing servers and repositories. Any 2.0 will have to provide more than just an upgrade path, it will have to keep all those repositories functional for both 1.x and 2.x clients. Here are some *not* valid reasons for 2.0: 1. Rewrite Subversion in another language That's just not going to happen. Yes, we can write new code in Rust/Go/D/Scala/whatever, *if* we decide that the whole world is winux and *BSD and we don't care about legacy systems. But aiming to replace the codebase with something new is the surest way to kill the project that I can think of. We're not likely to attract new developers if we plan to get bogged down for years without a major new release (remember, it took us 4 years to get from nothing to 1.0). 2. "I don't like the way feature X is implemented, let's replace it with something better" I can certainly understand and even share that feeling. However: a) see above under "20 years of stable code", and b) there are always ways to make improvements in a backward-compatible way. As a user of software, the thing I hate the most is when people gratuitously break API/ABI/UI compatibility for no better reason than "it's better this way." 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 actually being the hardest to change, due to hysterical ... um, I mean historical reasons). -- Brane
Re: Subversion 2.0
> [..] 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 for pull-requests. I think the Svn team should only concentrate on command line capability for that, and leave web UIs to the commercial teams - Assembla, RhodeCode, CollabNet. I also wrote something about Subversion on my blog a week or so ago - lesser known strengths and weaknesses - https://paulhammant.com/2019/06/14/merkle-trees-and-source-control/. Sure, there's some other attempt at a comparison with https://svnvsgit.com/, but that's not me. -ph
Re: Subversion 2.0
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 changes to Subversion will > make a difference at this point .. and I am not saying that is what you are > suggesting. I would want to be sold on some compelling new ideas for a > product, and then probably why building those ideas on the Subversion 1.x > code base makes sense. > Agreed 100%. The purpose of this thread is to have a community-wide brainstorming session to figure out exactly what we want from the Subversion of the future, for that very reason. As a cautionary tale I would look at Veracity. > http://veracity-scm.com/compare/ > > I struggle to find some of the original blog posts that Eric Sink made > when they were creating this product but I know they set out to fix a lot > of the shortcomings in Git and they did so using an Apache license. AFAIK, > they accomplished most of their initial goals and then went on to also > incorporate some of the ideas from Fossil in adding a distributed agile > tracker and wiki to the product as well. Despite all of this the product > landed with a thud and has been discontinued. Aside from wondering why it > would not be a better code base than Subversion to start a new product from > I come back to the compelling idea point. What are the ideas that are > going to move the needle? Who is the target audience? The corporate world > is probably still in play but it seems very difficult at this point to move > the open source world away from Git. > 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 attract new users and developers to Subversion must deal with Git (among other things). Veracity SCM tried to be a better Git. One could argue that Mercurial tried the same thing. But Git has been far more widely adopted, at least it appears that way in public, in the open source world. We don't know what goes on behind closed doors. Mercurial could be perceived as a Git wanna-be. It's easier to use but a little slower. Git blasted Mercurial out of the water because people generally don't like imitations. People want the real deal. Given the choice between real Git and imitation Git (even if it's not true; it's perceived), most people will probably choose real Git. That should give us a hint. The goal "be a better CVS" worked in 1999. "Be a better Git" will _not_ work in 2019. So we have to go a different way. My suggestions for a strategy with respect to Git: * Do not compete with Git in areas where Git is strong. Instead, cooperate with Git in those areas. * Compete with Git in areas where Git is weak. Do not compete with Git: I do not suggest to turn Subversion into a DVCS because we'll be perceived as imitation Git. Subversion is centralized and that is NOT a weakness. I'd like to point out that in 2004, Internet access was slow and therefore "everything is local" was a big selling point of Git. But in 2019, when broadband Internet is cheap, when cell phone plans come with mobile hotspot, with 5G on the horizon (and they're talking about massive amounts of data at near- instant speeds), this is becoming much less of a concern with every passing minute. People want to be on the same sheet of paper with each other. People are comfortable with "the cloud." As telecommunications get better and faster every day, Git's "everything is local" starts to become more of a liability than an asset. GitHub exists because people want and need a central repository. Like the saying goes, what's old is new again. Compete with Git: I suggest to start by amplifying the best things about Subversion that make it different and better than Git. But that's just incremental change. We need something more. As Mark said, we need something compelling. So I will close for now with the following question, which I have been asking myself: How can we leverage Subversion's centralized structure to give something _better_ than modern workflows? If we come up with some compelling ideas, it might be interesting to invite > Eric to conversation to share what they learned and why what they were > doing never worked. The one thing I can say is that while they were open > source and tried to create a community and be open maybe there are things > they could have done differently that would have had more impact ... such > as trying to make it an Apache Foundation product. > I would like as many people as possible to be invited to the conversation.
Re: Subversion 2.0
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 ports of Python pieces on UpWorks > for fixed prices and have always been impressed. If you choose a > "most depended on, and least depending, FIRST" strategy for flipping > to Rust, you could methodically transition to Rust from C/C++ and keep > shipping. > > If anything feels 2.x worthy, it's addressing the chatty nature of the > HTTP wire api. I don't think there'd be any appetite for that though, > as Greg Stein et al participated with the W3C to make HTTP 1.1 > (including WebDAV) in order to polish Svn's over-HTTP sid. And given > that the there's zero community interest in revisiting the WebDAV > spec, you'd be talking about a non-standard extension, and I'll be > there's no interest in that here. There may be. At the time, there was an expectation that WebDAV/DeltaV would become ubiquitous. The idea that a Subversion client could talk to any WebDAV or DeltaV server, and the obverse, was very exciting. But that went the way of so many exciting ideas, and in the end, our "HTTPv2" protocol ditched DeltaV entirely whilst playing only lip service to WebDAV. I think there's still a good reason to have an HTTP-based protocol, but something more streamlined and stateful and -- possibly -- requiring HTTP/2 features might be a better fit. And almost certainly something that wasn't tied to Apache HTTPd on the server side. -- Brane
Re: Subversion 2.0
> 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 and have always been impressed. If you choose a "most depended on, and least depending, FIRST" strategy for flipping to Rust, you could methodically transition to Rust from C/C++ and keep shipping. If anything feels 2.x worthy, it's addressing the chatty nature of the HTTP wire api. I don't think there'd be any appetite for that though, as Greg Stein et al participated with the W3C to make HTTP 1.1 (including WebDAV) in order to polish Svn's over-HTTP sid. And given that the there's zero community interest in revisiting the WebDAV spec, you'd be talking about a non-standard extension, and I'll be there's no interest in that here. -ph
Re: Subversion 2.0
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. Right now is the time to dream, out loud. What is your dream > version control system, if you could have it all? Why would it be that way? > > Subversion 2.0, The Idea Phase, now open for business. :-) > 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 changes to Subversion will make a difference at this point .. and I am not saying that is what you are suggesting. I would want to be sold on some compelling new ideas for a product, and then probably why building those ideas on the Subversion 1.x code base makes sense. As a cautionary tale I would look at Veracity. http://veracity-scm.com/compare/ I struggle to find some of the original blog posts that Eric Sink made when they were creating this product but I know they set out to fix a lot of the shortcomings in Git and they did so using an Apache license. AFAIK, they accomplished most of their initial goals and then went on to also incorporate some of the ideas from Fossil in adding a distributed agile tracker and wiki to the product as well. Despite all of this the product landed with a thud and has been discontinued. Aside from wondering why it would not be a better code base than Subversion to start a new product from I come back to the compelling idea point. What are the ideas that are going to move the needle? Who is the target audience? The corporate world is probably still in play but it seems very difficult at this point to move the open source world away from Git. If we come up with some compelling ideas, it might be interesting to invite Eric to conversation to share what they learned and why what they were doing never worked. The one thing I can say is that while they were open source and tried to create a community and be open maybe there are things they could have done differently that would have had more impact ... such as trying to make it an Apache Foundation product. The one thing I will throw out is that I think a new version control product will need to be written in Rust or Go to attract any attention, not that I have any experience with either language. A product written in C is not going to attract new developers - in my opinion. -- Thanks Mark Phippard http://markphip.blogspot.com/
