A bit late perhaps, but also from me a big +1 to this vision and
roadmap proposal.
There are some minor points which can be discussed of course (as
always), but overall I think it's a very good plan. I especially
applaud the initiative itself to spend some time for this, taking a
step back, looking a bit further down the road than just the next
minor release or the next fire that needs to be put out, trying to get
the community more focused and more active, ...
This is all very important, so thanks to all who participate(d). I
hope you guys can repeat this kind of gettogether once in a while, to
toss ideas around, to provide continuing direction, ...
Some detailed responses to the proposal and to the other replies below.
On Fri, Apr 2, 2010 at 5:28 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> VISION
> [...]
> Subversion exists to be universally recognized and adopted as an
> open-source, centralized version control system characterized by its
> reliability as a safe haven for valuable data; the simplicity of its
> model and usage; and its ability to support the needs of a wide variety
> of users and projects, from individuals to large-scale enterprise
> operations.
>
> A shorter, business-card-sized motto (offered as a replacement to the
> obsolete "A compelling replacement for CVS") might be: "Enterprise-class
> centralized version control for the masses".
Absolutely spot on. Subversion needs to be the best out there for
centralized version control (which is what enterprises usually
need/want). It has no place in the DVCS world.
Like it probably also happens in other companies, in our company there
are some grassroots experiments of using DVCS's. But it's not their
distributedness that attracts our developers, it's simply because they
are faster to work with, have better merging capabilities, better
handling of renames, ... things that AFAICS do not depend on the
distributed nature of the VCS. If Subversion would be able to catch up
with the DVCS's in these areas (both feature-wise and especially
performance-wise), I see no reason to prefer a DVCS (except of course
if you need the D because you require your VCS to be uh ...
distributed).
> ROADMAP
> [...]
> 1.7: WC-NG; HTTPv2; 'svn patch'; typical slew of various bug fixes
Eagerly awaiting WC-NG here. We need *fast* working copies (that know
how to preserve all the information of arbitrary series of
adds/moves/copies/renames/modifications/deletes correctly), and we
need them now ;-). Cheering you guys on for 1.7-ness ...
> 1.8: repository-dictated configuration; tree conflicts improvements;
> WC-NG-enabled stuff (rename tracking, compressed pristines,
> shelving/checkpointing, ...)
Yes, tree conflicts improvements and rename tracking are absolutely
critical. I know they have to wait for WC-NG right now, but boy do we
need them... It's good to see them proposed for 1.8.
Great also to see repository-dictated configuration come into the
picture. In an enterprise environment the lack of this feature has
always been kind of embarrassing (having to catch things in a
pre-commit hook, and telling your users they have to install the
correct config in their client, ...), and also a huge waste of time.
> 1.9: Editor v2 (for server->client rename handling improvements)
>
> [...]
>
> 2.0: FS-NG (ideally a parallelized task), with some (to-be-identified)
> FS-NG enabled features.
>
> That last item is likely to be contentious, so it bears explaining. We
> believe that our current two filesystem offerings are stifling innovation.
> On the one hand we have the BDB backend which is a breeze to develop for but
> is only occasional used; on the other is the far-more-popular FSFS backend
> whose fundamental principles so constrain the system as to destroy much hope
> of serious design overhaul; and in the middle lies the feature parity
> requirement we've been living under thus far which binds Subversion to the
> union of the two backends' weaknesses. We confidently assert that to break
> system-wide compatibility with a so-called 2.0 release will be Subversion's
> great overall detriment, both from the perspective of efficient use of
> development energy and in user adoption. So we propose that an
> as-yet-fictional Subversion 2.0 be allowed to break compatibility with the
> 1.x line only in ways which can be mitigated using the RA layer as a
> compatibility shim. Additionally, we believe that merely releasing a 2.0
> with a new FS backend but without new user-visible features enabled by that
> overhaul will be ill-received.
This is the first I hear of FS-NG, but I'm quite enthousiastic. I
completely understand the rationale that you give above.
I especially hope that FS-NG will be *fast*. We use FSFS and I've
always felt that it's not very much designed for performance
(especially for big read operations like log, blame, checkout, ...
which have to do way too much I/O to get the job done). Thinking back
right now to a quote of Jon Trowbridge in a recent thread
(http://svn.haxx.se/dev/archive-2010-03/0735.shtml): "Subversion
assumes that I/O is essentially free. But in a cloud-based FS, that's
not true." Well I can assure you, cloud-based FS or not, this is
*never true* (unless your back-end is on a local SSD, and even then
...).
Of course you guys are probably thinking much further/deeper than just
performance, but for me that's one of the most important things right
now. If FS-NG would be an order of magnitude faster for some of those
massive read operations, that would be a compelling reason for me to
upgrade as quickly as possible :).
> COMMUNITY
> [...]
> But communication alone isn't enough. We need to find ways to grow our
> developer community itself.
Very true. I have some observations about this myself ("from the other
side"), but will put them in a separate thread...
---------
Some more responses to the intermediate replies below...
On Mon, Apr 5, 2010 at 5:06 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> The same goes for merging. E.g. DCVS tools simply don't have the concept
> of doing tracked subtree merges (so merging is always damn easy and even
> ruby on rails programmers get it ;), nor do they have the concept of mixed
> revision working copies. But svn does support these concepts and they
> add a lot of complexity. E.g. users end up doing subtree merges by mistake,
> creating mergeinfo all over the place. They don't realise that the normal
> use case is to have mergeinfo only on the branch root, and not doing any
> subtree merges.
I think it's also often done simply to merge quicker. If you merge
only the specific subtree which you know is affected by your
cherrypick merge, you can merge orders of magnitude faster than if you
merge the same cherrypick merge to the root of the branch. Most svn
end users who don't fully grok how merge works will not understand
that it makes a difference (why should it? I *know* this revision only
affects this subtree, so I can just merge it here directly, no?). They
think they have found a good workaround for merging faster.
So ultimately this is again a performance issue... (maybe WC-NG will
help a lot for this?)
On Tue, Apr 6, 2010 at 10:22 PM, Branko Čibej <brane_at_xbc.nu> wrote:
> On 06.04.2010 12:18, Stefan Sperling wrote:
>> On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
>>
>>> On 05.04.2010 17:06, Stefan Sperling wrote:
>>>
>>>> An idea we're playing with to mitigate this problem is having designated
>>>> properties in the svn: namespace which allow users to tell svn what their
>>>> branching/merging strategy is.
>>>>
>>> (Thereby making things even more flexible, complex, and error-prone.)
>>> In the light of previous discussions
>>>
>> I'd like to read them. Can you provide pointers?
>>
>
> I was referring to previous posts to this thread.
>
>>> this is a less than optimal way of
>>> making branching and merging easier for users. This is another feature
>>> that would probably only be used by perhaps 1% of all users ...
>>>
>> Do you mean "used" or "configured" (as in setting the props)?
>>
>
> I mean "configured" but "used" works just as well because that's where
> the complexity and maintenance burden comes in. Such properties are
> pretty much equivalent to mergeinfo in the sense that they control the
> behaviour of the client and server, and would have the same tendency
> towards complex edge cases and unexpected usage scenarios.
>
>>> whilst
>>> most people just want to say, "create a branch" and "merge from that
>>> branch" and be done with it.
>>>
>> Yes, they do.
>>
>> But how else would you make it easier to use before going 2.0
>> (in the "2.0" sense of writing a new centralised SCM from scratch)?
>> The flexibility^Wcomplexity is there now, and we have set for
>> ourselves the goal to continue supporting it (for better or worse).
>>
>
> I've proposed before that we introduce proper branches, and gradually
> phase out support for the copy-is-branch paradigm, for example, by not
> supporting smart merging between directory copies but only between
> branches. There is no good reason to continue to support every feature
> we've ever had, assuming we provide a migration path *and* publish a
> roadmap so that users can be made aware of such upcoming changes.
>
> -- Brane
>
I agree with Brane here. I think the only way to really tackle this
area is to make "branches" and "tags" first class citizens
(disregarding for a moment how difficult this might be to
implement/add and what consequences this will have). Not working
towards this goal will likely be patchwork, adding even more
complexity both for developers and for users.
I have no idea how this could be integrated with svn's
model/architecture, but it might be a good idea to start thinking
about this for 2.0 ... it just might be the right time to say to
people: "look, you have to use this new proper branching/tagging
system if you want quality merge support etc. Feel free to continue
using the old copy-is-branch/tag system, but know that its
functionality is limited (i.e. svn cannot be as smart with them as it
can be with proper branches)"
But as I said, I can offer zero contribution on how to accomplish this
technically ...
--
Johan
Received on 2010-04-08 14:57:16 CEST