You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2012/07/11 15:50:59 UTC
Re: Format bump for 1.8?
I'd like to continue this discussion a bit more, as there are still
some things lingering here ...
On Thu, Jun 28, 2012 at 1:32 AM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling <st...@elego.de> wrote:
>>> On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote:
>>...
>>> I would prefer to by default keep working copy upgrades manual from now on.
>>
>> +1, let's please keep it an explicit action by the user.
>
> Not sure about that. The user will type 'svn move' and not get the
> benefits. All the docs will say it *should* work, but it doesn't.
>
> Oh... right. The user didn't bother to upgrade the working copy. Gee. Too bad.
>
> That's rather confusing.
>
> What other features won't work?
Yes, I agree we'd have to make it clear in our docs that feature X
depends on working copy format Y. That's an additional effort, yes.
But for the book or the FAQ it's not a lot different from phrases
where they now say: "If you've got Subversion 1.7 or higher, you'll
get ...". Then they'll have to say "If your working copy format is 1.8
or higher, you'll get ...".
For our commandline help output it's probably a bit more difficult:
we'll need to find a concise and elegant way to annotate certain
descriptions in the help output as "only for wc format >= x.y".
Some things that are also probably needed:
- Mention working copy format/version in output of 'svn info' (like we
also give 'Working Copy Root Path' since 1.7).
- Maybe have an explicit subcommand that just reports the wc format
(nice for scripts, if they want to do things conditional on the wc
format -- no need to parse it out of 'info' output). Alternatively, if
explosion of subcommands is a concern, I envisage options for the
'info' command that only give one particular piece of info (or
something like that ... a topic for another thread).
>>...
>>>> However: we don't have a good concept of "read-only vs read-write"
>>>> operations at the wc_db level, like we used to have with the entries
>>>> file. As soon as we touch a working copy (eg. "svn info" or "svn
>>>> status"), then we would likely perform the auto-upgrade. We might need
>>>> some decent tooling to go back to the "only upgrade when writing"
>>>> model. For example, maybe when an administrative lock is constructed,
>>>> then we check for an old format and perform the auto-upgrade before
>>>> continuing the (modifying) operation.
>>
>> Ok, but if we keep upgrade an explicit action, this won't be a
>> problem, right? No need to determine whether to auto-upgrade or not.
>
> If we don't auto-upgrade... sure. But I think we should continue to
> auto-upgrade in the general case. We did it for years without horrible
> user feedback (afaik).
As I said elsethread, most end-users I know consider the "manual
upgrade" in 1.7 a clear improvement over auto-upgrading. It makes the
entire process less scary. It avoids accidents like the scenario I
mentioned, where the user has 3 svn clients (a commandline client, a
GUI tool, and an IDE plugin), which all have their own release cycles.
In that situation, an auto-upgrade by one of the three, while another
can't be upgraded immediatly, can wreak havoc. It's much better to
error out with 'working copy format too old, run svn upgrade'.
Also, as I said, an auto-upgrade needs at least:
- To be reversible (need downgrade feature or script).
- To be fast, and O(1) (consider 1,000,000 nodes WCs).
Now, there is another use case: a build server with 1000 working
copies, and a single svn client. In that case, a fast auto-upgrade is
nice, otherwise it's hard to upgrade the svn client (need to manually
upgrade 1000 working copies). But OTOH, if svn 1.8 would have a
1.7-compat mode, that chicken-and-egg problem would also go away
nicely: upgrade the svn client to 1.8, everything keeps working, and
those 1000 working copies can be upgraded whenever you like.
>> If the code could work with older working copy formats, then there's
>> also no immediate need for the user to upgrade, unless he wants to
>> take advantage of newer features.
>
> Confusing. And hidden. And yet another variable in the user's
> config/environment that will throw off our ability to support them.
> "Wait. You didn't upgrade your working copy? Go away. You're pissing
> me off."
Agreed, it's another variable to consider when reporting problems and
such. Still, I think most users would appreciate the additional
flexibillity of backwards compatibility with older wc formats.
Of course we should try our best to educate users about this, and to
give them enough information. Like extending the feature compatibility
table in the release notes with a "Minimum working copy format"
column.
Maybe we should ask around on the users-list to get a feel for what
most users think/want.
>> I think the question is: is there a willingness in the community to
>> take on the additional burden of making the code flexible enough, so
>> it can work with multiple working copy formats? Making some code paths
>> conditional on the working copy version in one way or another?
>
> Some. Sure.
>
>> (As I noted before, svnkit has this special ability: the latest
>> version (1.7.5) can work with working copies in 1.3, 1.4, 1.5, 1.6 and
>> 1.7 formats, without upgrading them. It's effectively a backwards
>> compatible client. That makes svnkit a very interesting svn client in
>> some environments / situations. I just wish svn itself could do the
>> same ...).
>
> There was absolutely no way to get the wc-ng benefits and still write
> to the old .svn/entries. The entire working copy library was rebuilt.
>
> If we didn't not have a separate client vs wc API, then it *may* have
> been possible to support older formats more easily. When you're only
> talking about client APIs that do $FOO, then the actual storage format
> becomes much less important. You just want to munge it from one state
> to another.
>
> But we have an independent working copy library that allows a lot of
> detailed operations. Supporting those across multiple formats was
> simply not a workable answer.
Just to be clear: I totally understand that this was nearly impossible
to do for 1.7. But I'm only looking at the future here :-). Can we do
better with 1.8 and beyond?
Also, I'm not suggesting that we support new-in-1.8 semantics with a
1.7-WC. Just that the 1.8 client can support 1.7-semantics with a
1.7-WC. I'm asking if it would be possible that a 1.8 client can run
in 1.7-compat mode if it runs on a 1.7-WC. That's effectively what
svnkit and maybe other clients do (AFAIK, they could just be packaging
different clients in one package, and have some kind of dispatch /
polymorphism /... in place that delegates to the correct client
depending on the wc-version).
--
Johan
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 11, 2012 at 4:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
>> Sent: woensdag 11 juli 2012 15:51
>> To: Greg Stein
>> Cc: dev@subversion.apache.org
>> Subject: Re: Format bump for 1.8?
>>
>> I'd like to continue this discussion a bit more, as there are still
>> some things lingering here ...
>
>> Also, as I said, an auto-upgrade needs at least:
>> - To be reversible (need downgrade feature or script).
>> - To be fast, and O(1) (consider 1,000,000 nodes WCs).
>
> Note that there was a repeated expensive table scan in the upgrade process
> for 1.7, which was fixed in r1342984 and merged back to 1.7.x in r1349817,
> but still not released.
>
> O(1) is impossible for most database schema changes except adding empty
> tables, but O(n) should be doable. (Creating an index on some data is more
> expensive than O(n), and simply changing every record O(n))
> The 1.7 upgrade was O(n^2), until r1342984.
>
> The format bump required for conflict skels is currently still O(n), except
> for adding an index on the file move a fields that are always NULL in 1.7.
No problem. Note that I specifically said "an *auto-upgrade* needs
...". And 1.7 is manual-upgrading, so it's much less of an issue (user
knows what's going on, he asked for an upgrade after all).
Maybe O(1) is a bit overkill (in <= 1.6 the auto-upgrades were at
least O(number of directories)). But anyway, since the consensus in
this thread is leaning towards "manual upgrade", it's probably a moot
discussion about what I expect from auto-upgrade ...
--
Johan
AW: Format bump for 1.8?
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
> Von: Bert Huijben [mailto:bert@qqmail.nl]
> > From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> >
> > I'd like to continue this discussion a bit more, as there are still
> > some things lingering here ...
>
> > Also, as I said, an auto-upgrade needs at least:
> > - To be reversible (need downgrade feature or script).
> > - To be fast, and O(1) (consider 1,000,000 nodes WCs).
>
> Note that there was a repeated expensive table scan in the upgrade process
> for 1.7, which was fixed in r1342984 and merged back to 1.7.x in r1349817,
> but still not released.
>
> O(1) is impossible for most database schema changes except adding empty
> tables, but O(n) should be doable. (Creating an index on some data is more
> expensive than O(n), and simply changing every record O(n)) The 1.7
> upgrade was O(n^2), until r1342984.
>
> The format bump required for conflict skels is currently still O(n),
> except for adding an index on the file move a fields that are always NULL
> in 1.7.
One of the most annoying things in the upgrade from 1.6 to 1.7 was that certain conditions prevented a successful update, and which could not be solved without an 1.6 client.
Most of those were fixed as bugs, (like lock tokens in the local wc), but a major one remained: working copies needing a "cleanup".
>From an users perspective, it is a very annoying experience when he upgrades his SVN client(s), and then some days later stumbles across a working copy which he cannot upgrade without downgrading one of his clients.
As the 1.7 and 1.8 working copy format changes are only "minor" ones from an architectural view, do you think the upgrade could handle this case better this time?
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Format bump for 1.8?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel@gmail.com]
> Sent: woensdag 11 juli 2012 15:51
> To: Greg Stein
> Cc: dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> I'd like to continue this discussion a bit more, as there are still
> some things lingering here ...
> Also, as I said, an auto-upgrade needs at least:
> - To be reversible (need downgrade feature or script).
> - To be fast, and O(1) (consider 1,000,000 nodes WCs).
Note that there was a repeated expensive table scan in the upgrade process
for 1.7, which was fixed in r1342984 and merged back to 1.7.x in r1349817,
but still not released.
O(1) is impossible for most database schema changes except adding empty
tables, but O(n) should be doable. (Creating an index on some data is more
expensive than O(n), and simply changing every record O(n))
The 1.7 upgrade was O(n^2), until r1342984.
The format bump required for conflict skels is currently still O(n), except
for adding an index on the file move a fields that are always NULL in 1.7.
Bert
Re: Format bump for 1.8?
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> "Bert Huijben" <be...@qqmail.nl> writes:
>
>> Are there any other changes waiting for a format bump right now?
>
> What about the index changes I made in r1002793? We should probably
> arrange for those to get applied to 1.7 working copies.
Oops! Those are already in 1.7.
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Format bump for 1.8?
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
> Are there any other changes waiting for a format bump right now?
What about the index changes I made in r1002793? We should probably
arrange for those to get applied to 1.7 working copies. Some of the
other indices could be made UNIQUE--perhaps the format bump should do
that as well.
--
Cerified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: Format bump for 1.8?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: woensdag 11 juli 2012 16:39
> To: Bert Huijben
> Cc: 'Hyrum K Wright'; 'Johan Corveleyn'; 'Greg Stein';
> dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> On 07/11/2012 10:37 AM, Bert Huijben wrote:
> > Are there any other changes waiting for a format bump right now?
>
> I can't recall now: did the new MD5 index into the pristines require a
> format bump?
Yes, to introduce it in an existing database requires a bump.
It is already in the bump script for format 30, so I already tested that one with the conflict skel work.
Bert
Re: Format bump for 1.8?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/11/2012 10:37 AM, Bert Huijben wrote:
> Are there any other changes waiting for a format bump right now?
I can't recall now: did the new MD5 index into the pristines require a
format bump?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
RE: Format bump for 1.8?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: woensdag 11 juli 2012 16:27
> To: C. Michael Pilato
> Cc: Johan Corveleyn; Greg Stein; dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
> I agree with Mike on all of the above.
>
> > I actually feel like the 1.7 situation was the best we've had to date:
> > restrictive WC format client support, an explicit upgrade step, minimal
> > surprises.
>
> Agreed. Most of the feedback I've heard was that the 1.7 upgrade
> experience was actually better than previous cycles, even though
> technically t was the most radical.
Note that the new skel based conflict storage, which is mostly ready on
trunk requires a format bump for enabling.
If you enable it and run our test suite all tests pass, but I think the
upgrade code needs a bit more testing. And we have to decide when we bump
the current format.
Are there any other changes waiting for a format bump right now?
Bert
>
> -Hyrum
Re: Format bump for 1.8?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jul 11, 2012 at 9:23 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 07/11/2012 09:50 AM, Johan Corveleyn wrote:
>> Yes, I agree we'd have to make it clear in our docs that feature X
>> depends on working copy format Y. That's an additional effort, yes.
>> But for the book or the FAQ it's not a lot different from phrases
>> where they now say: "If you've got Subversion 1.7 or higher, you'll
>> get ...". Then they'll have to say "If your working copy format is 1.8
>> or higher, you'll get ...".
>
> Documentation-wise, I don't see this as much more problematic than "If
> you're server was created with Subversion 1.5 or better, the mergeinfo
> feature is available."
>
>> As I said elsethread, most end-users I know consider the "manual
>> upgrade" in 1.7 a clear improvement over auto-upgrading. It makes the
>> entire process less scary. It avoids accidents like the scenario I
>> mentioned, where the user has 3 svn clients (a commandline client, a
>> GUI tool, and an IDE plugin), which all have their own release cycles.
>> In that situation, an auto-upgrade by one of the three, while another
>> can't be upgraded immediatly, can wreak havoc. It's much better to
>> error out with 'working copy format too old, run svn upgrade'.
>
> Agreed. Working copy auto-upgrade has been a repeated point of concern by
> our users over the years, for the scenario you gave as well as for the
> situation where users share working copies. (A similar situation drives the
> reason why we don't auto-upgrade repositories -- multiple users hitting a
> repository over ra_local with different client versions.)
>
> That said, I'm not really in favor of us maintaining multiple codepaths
> (based on WC version) in the client. I just don't see the cost justifying
> the benefit. I mean, it makes sense to do so in the repositories as we do
> today, because the cost of any Subversion upgrade could be equivalent to the
> cost of a full dump/load of the repository. I think that's too much to ask
> of our administrators. But for working copies?
I agree with Mike on all of the above.
> I actually feel like the 1.7 situation was the best we've had to date:
> restrictive WC format client support, an explicit upgrade step, minimal
> surprises.
Agreed. Most of the feedback I've heard was that the 1.7 upgrade
experience was actually better than previous cycles, even though
technically t was the most radical.
-Hyrum
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jul 13, 2012 at 11:10 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Thu, Jul 12, 2012 at 23:29:06 +0200:
...
>> But I'm trying to state the problem more generally: most users have
>> different clients, and those can have different release cycles. For
>> whatever reason. I think it's naive to ignore that problem.
>>
>
> Okay. But in that case, the problem you claim is disregarded has
> nothing to do with svnkit...
Indeed, and I never said it had (except as an example of a situation
where you have multiple clients with different release schedules).
>> >> I guess this is theoretically possible. But as a Windows user, I
>> >> personally wouldn't like it. This is exactly one of the things that
>> >> annoys me every time when I'm working on e.g. Solaris: What? I can't
>> >> have two different svn versions installed at the same time? On my
>> >> central build server with 1000 working copies I can't just quickly
>> >> install a 1.7 version to do some tests, while all my colleagues keep
>> >> on running svn 1.6 for the real stuff. Gah.
>> >>
>> >
>> > Of course you can, just don't install it to the same $prefix as
>> > everything else. On svn.apache.org we have 6 different svn
>> > installations...
>>
>> Okay, maybe I can. But it's hard, especially because I'm not a
>> sysadmin myself on that system, can't build from source, so I have to
>> depend on installable third-party packages (Solaris packages in this
>> case). But okay, maybe this is going a bit in too much detail about my
>> particular situation ... don't want to bring in my organizational
>> problems into the equation :-) ...
>>
>> But on Windows, I could just zip some svnclient from another system,
>> and unzip it into C:\Temp or whatever, and test whatever I want.
>
> ./configure --enable-all-static ???
As I said, I don't have a build environment, don't have all the
necessary dependencies, don't want to spend time figuring this out etc
... I'm looking for a binary distribution which I can just drop in my
home directory and that will just work. But nobody seems to distribute
all-static binaries for Solaris ... it's not the unix way, I guess.
Anyway, this is probably digressing too much into a discussion of
platforms and OS'es, things that we have no control over anyway ...
--
Johan
Re: Format bump for 1.8?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Jul 12, 2012 at 23:29:06 +0200:
> On Thu, Jul 12, 2012 at 10:56 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Thu, Jul 12, 2012 at 22:19:50 +0200:
> >> On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson <pe...@p12n.org> wrote:
> >> > [Markus Schaber]
> >> >> So my personal experience tells me that multiple-client scenarios are
> >> >> the common case, and that the deployment strategy (only using linux
> >> >> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> >> >> problem.
> >> >
> >> > So, we provide a pile of libraries that maintain ABI backward
> >> > compatibility. You can have as many different svn client apps on a
> >> > given system as you want, and so long as they are all using the same
> >> > copy of our libraries, there is no cross-version compatibility problem.
> >> >
> >> > (Of course, there's two other related issues: 1) sharing a wc across
> >> > two or more systems; 2) use of SVNKit. I'll ignore both for now;
> >> > SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
> >>
> >> I think it's sad that there is so much antagonism against SVNKit in
> >> this community. With my svn user hat on, I consider SVNKit as just
> >> another part of the svn ecosystem. As a user, I don't really care if
> >> it's implemented in C, in Java or in Turbo Pascal :-), as long as it
> >> plays by the rules and acts like any other svn client. Besides, in our
> >> environment I have no choice but to use SVNKit: the svn plugin of my
> >> IDE (IntelliJ IDEA) only works with SVNKit.
> >>
> >> I think it would be beneficial for the svn ecosystem as a whole if
> >> this community would try to build better relations with the SVNKit
> >> people. Some mutual understanding certainly wouldn't hurt. I was very
> >> happy to see more interest by the SVNKit guys in the core project, and
> >> see their presence at the Berlin Hackathon (hi Dmitry :-)).
> >>
> >
> > I don't think there is antagonism against svnkit here; just "they chose
> > not to use our APIs, so if things break because of that it's their
> > problem to fix and not ours".
>
> To restate what I said on IRC: things are not breaking because of
> SVNKit (they easily support all working copy formats back to 1.3 with
> their 1.7 client), it's because of the native clients :-), that insist
> on upgrading themselves (nagging the user that there is a new version
> that they should upgrade to) and on upgrading the working copies.
> Combined with the fact that some software of the user depends upon
> SVNKit for their svn support, and SVNKit's release was lagging behind
> for 1.7.
>
> But I'm trying to state the problem more generally: most users have
> different clients, and those can have different release cycles. For
> whatever reason. I think it's naive to ignore that problem.
>
Okay. But in that case, the problem you claim is disregarded has
nothing to do with svnkit...
> >> I guess this is theoretically possible. But as a Windows user, I
> >> personally wouldn't like it. This is exactly one of the things that
> >> annoys me every time when I'm working on e.g. Solaris: What? I can't
> >> have two different svn versions installed at the same time? On my
> >> central build server with 1000 working copies I can't just quickly
> >> install a 1.7 version to do some tests, while all my colleagues keep
> >> on running svn 1.6 for the real stuff. Gah.
> >>
> >
> > Of course you can, just don't install it to the same $prefix as
> > everything else. On svn.apache.org we have 6 different svn
> > installations...
>
> Okay, maybe I can. But it's hard, especially because I'm not a
> sysadmin myself on that system, can't build from source, so I have to
> depend on installable third-party packages (Solaris packages in this
> case). But okay, maybe this is going a bit in too much detail about my
> particular situation ... don't want to bring in my organizational
> problems into the equation :-) ...
>
> But on Windows, I could just zip some svnclient from another system,
> and unzip it into C:\Temp or whatever, and test whatever I want.
./configure --enable-all-static ???
>
> --
> Johan
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jul 12, 2012 at 10:56 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Thu, Jul 12, 2012 at 22:19:50 +0200:
>> On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson <pe...@p12n.org> wrote:
>> > [Markus Schaber]
>> >> So my personal experience tells me that multiple-client scenarios are
>> >> the common case, and that the deployment strategy (only using linux
>> >> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
>> >> problem.
>> >
>> > So, we provide a pile of libraries that maintain ABI backward
>> > compatibility. You can have as many different svn client apps on a
>> > given system as you want, and so long as they are all using the same
>> > copy of our libraries, there is no cross-version compatibility problem.
>> >
>> > (Of course, there's two other related issues: 1) sharing a wc across
>> > two or more systems; 2) use of SVNKit. I'll ignore both for now;
>> > SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
>>
>> I think it's sad that there is so much antagonism against SVNKit in
>> this community. With my svn user hat on, I consider SVNKit as just
>> another part of the svn ecosystem. As a user, I don't really care if
>> it's implemented in C, in Java or in Turbo Pascal :-), as long as it
>> plays by the rules and acts like any other svn client. Besides, in our
>> environment I have no choice but to use SVNKit: the svn plugin of my
>> IDE (IntelliJ IDEA) only works with SVNKit.
>>
>> I think it would be beneficial for the svn ecosystem as a whole if
>> this community would try to build better relations with the SVNKit
>> people. Some mutual understanding certainly wouldn't hurt. I was very
>> happy to see more interest by the SVNKit guys in the core project, and
>> see their presence at the Berlin Hackathon (hi Dmitry :-)).
>>
>
> I don't think there is antagonism against svnkit here; just "they chose
> not to use our APIs, so if things break because of that it's their
> problem to fix and not ours".
To restate what I said on IRC: things are not breaking because of
SVNKit (they easily support all working copy formats back to 1.3 with
their 1.7 client), it's because of the native clients :-), that insist
on upgrading themselves (nagging the user that there is a new version
that they should upgrade to) and on upgrading the working copies.
Combined with the fact that some software of the user depends upon
SVNKit for their svn support, and SVNKit's release was lagging behind
for 1.7.
But I'm trying to state the problem more generally: most users have
different clients, and those can have different release cycles. For
whatever reason. I think it's naive to ignore that problem.
>> I guess this is theoretically possible. But as a Windows user, I
>> personally wouldn't like it. This is exactly one of the things that
>> annoys me every time when I'm working on e.g. Solaris: What? I can't
>> have two different svn versions installed at the same time? On my
>> central build server with 1000 working copies I can't just quickly
>> install a 1.7 version to do some tests, while all my colleagues keep
>> on running svn 1.6 for the real stuff. Gah.
>>
>
> Of course you can, just don't install it to the same $prefix as
> everything else. On svn.apache.org we have 6 different svn
> installations...
Okay, maybe I can. But it's hard, especially because I'm not a
sysadmin myself on that system, can't build from source, so I have to
depend on installable third-party packages (Solaris packages in this
case). But okay, maybe this is going a bit in too much detail about my
particular situation ... don't want to bring in my organizational
problems into the equation :-) ...
But on Windows, I could just zip some svnclient from another system,
and unzip it into C:\Temp or whatever, and test whatever I want.
--
Johan
Re: Format bump for 1.8?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Jul 12, 2012 at 22:19:50 +0200:
> On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson <pe...@p12n.org> wrote:
> > [Markus Schaber]
> >> So my personal experience tells me that multiple-client scenarios are
> >> the common case, and that the deployment strategy (only using linux
> >> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> >> problem.
> >
> > So, we provide a pile of libraries that maintain ABI backward
> > compatibility. You can have as many different svn client apps on a
> > given system as you want, and so long as they are all using the same
> > copy of our libraries, there is no cross-version compatibility problem.
> >
> > (Of course, there's two other related issues: 1) sharing a wc across
> > two or more systems; 2) use of SVNKit. I'll ignore both for now;
> > SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
>
> I think it's sad that there is so much antagonism against SVNKit in
> this community. With my svn user hat on, I consider SVNKit as just
> another part of the svn ecosystem. As a user, I don't really care if
> it's implemented in C, in Java or in Turbo Pascal :-), as long as it
> plays by the rules and acts like any other svn client. Besides, in our
> environment I have no choice but to use SVNKit: the svn plugin of my
> IDE (IntelliJ IDEA) only works with SVNKit.
>
> I think it would be beneficial for the svn ecosystem as a whole if
> this community would try to build better relations with the SVNKit
> people. Some mutual understanding certainly wouldn't hurt. I was very
> happy to see more interest by the SVNKit guys in the core project, and
> see their presence at the Berlin Hackathon (hi Dmitry :-)).
>
I don't think there is antagonism against svnkit here; just "they chose
not to use our APIs, so if things break because of that it's their
problem to fix and not ours".
> I guess this is theoretically possible. But as a Windows user, I
> personally wouldn't like it. This is exactly one of the things that
> annoys me every time when I'm working on e.g. Solaris: What? I can't
> have two different svn versions installed at the same time? On my
> central build server with 1000 working copies I can't just quickly
> install a 1.7 version to do some tests, while all my colleagues keep
> on running svn 1.6 for the real stuff. Gah.
>
Of course you can, just don't install it to the same $prefix as
everything else. On svn.apache.org we have 6 different svn
installations...
> --
> Johan
RE: Format bump for 1.8?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Peter Samuelson [mailto:peter@p12n.org]
> Sent: donderdag 12 juli 2012 19:31
> To: Markus Schaber
> Cc: dev@subversion.apache.org
> Subject: Re: Format bump for 1.8?
>
>
> [Markus Schaber]
> > So my personal experience tells me that multiple-client scenarios are
> > the common case, and that the deployment strategy (only using linux
> > distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> > problem.
>
> So, we provide a pile of libraries that maintain ABI backward
> compatibility. You can have as many different svn client apps on a
> given system as you want, and so long as they are all using the same
> copy of our libraries, there is no cross-version compatibility problem.
>
> (Of course, there's two other related issues: 1) sharing a wc across
> two or more systems; 2) use of SVNKit. I'll ignore both for now;
> SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
>
> But IMO, we need to encourage using a _single_ copy of the Subversion
> libraries for all your clients. As you noted, that's how things work
> in integrated OSes like Linux distributions. It is unfortunate that
> the Windows world has a long cultural history of bundling dependencies
> into every installer, which obviously works against this goal.
>
> Is there some way we could push back? Encourage downstream developers
> to settle on a common libsvn installation? If they have to bundle it
> for ease-of-installation purposes, can they do so in such a way that,
> from a system perspective, it's two independent components? Basically
> bundle a common libsvn _installer_, instead of bundling libsvn (and of
> course apr / apr-util / apr-iconv and their dependencies) into your
> base package?
>
> I think there's precedent for this approach - e.g., the way some
> Windows installers will bundle a copy of VC++ runtime libraries, or the
> .NET CLR, in case you don't have a new enough one already.
>
> But I suppose for this to be workable, we would have to stop relying on
> third parties to build our Windows installers, and actually build one
> ourselves. Is this feasible?
This sounds like, let's break compatibility to introduce a new kind of
compatibility to me.
Given that on Windows several Subversion distributions use different C
runtimes I don't think it will be easy to reach consensus.
The distributions that switch to a central installation first are the most
likely to break when they encounter other installations.
And installing in a central location will introduce even more problems,
because libraries like openssl and zlib have incompatible versions in the
wild.
(We found lots of them when we tried using a central installation in AnkhSVN
0.X and 1.X)
I'm not looking forward to this process. The SlikSvn binaries explicitly
took the opposite approach: Make sure there are 0 library name conflicts, by
giving every shared library a product prefix.
Bert
Re: Format bump for 1.8?
Posted by Greg Stein <gs...@gmail.com>.
On Jul 13, 2012 6:30 AM, "Branko Čibej" <br...@wandisco.com> wrote:
>...
> I'm just saying it can be done, not that we should do it. On the other
> hand, looking specifically at supporting older WC formats in newer
> client versions -- that /is/ a feature that bears thinking about.
Feel free. I will state we already have support for them, and it is called
'svn upgrade'.
:-)
Cheers,
-g
Re: Format bump for 1.8?
Posted by Branko Čibej <br...@wandisco.com>.
On 13.07.2012 12:40, Hyrum K Wright wrote:
> On Fri, Jul 13, 2012 at 5:32 AM, Branko Čibej <br...@wandisco.com> wrote:
>> ...
>> And really, there's no reason why the Subversion command-line client
>> shouldn't do the same thing -- in fact, this is by far the easiest way
>> to support multiple working copy formats, even if it is less than
>> optimal as far as installed binary size is concerned (not to mention
>> release management and version juggling and testing).
> But why should we, as an open source project that only ships source
> code, worry about this? It sounds like a job for the folks that
> package binaries, either via OS package management systems or the
> various other binary providers around.
>
> If the solution you suggest is "ship several versions of the libraries
> in the same binary," it just doesn't feel like something we should do
> (or worry about, frankly).
I'm just saying it can be done, not that we should do it. On the other
hand, looking specifically at supporting older WC formats in newer
client versions -- that /is/ a feature that bears thinking about.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Format bump for 1.8?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Fri, Jul 13, 2012 at 5:32 AM, Branko Čibej <br...@wandisco.com> wrote:
>...
> And really, there's no reason why the Subversion command-line client
> shouldn't do the same thing -- in fact, this is by far the easiest way
> to support multiple working copy formats, even if it is less than
> optimal as far as installed binary size is concerned (not to mention
> release management and version juggling and testing).
But why should we, as an open source project that only ships source
code, worry about this? It sounds like a job for the folks that
package binaries, either via OS package management systems or the
various other binary providers around.
If the solution you suggest is "ship several versions of the libraries
in the same binary," it just doesn't feel like something we should do
(or worry about, frankly).
-Hyrum
Re: Format bump for 1.8?
Posted by Branko Čibej <br...@wandisco.com>.
On 12.07.2012 18:31, Peter Samuelson wrote:
> [Markus Schaber]
>> So my personal experience tells me that multiple-client scenarios are
>> the common case, and that the deployment strategy (only using linux
>> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
>> problem.
> So, we provide a pile of libraries that maintain ABI backward
> compatibility. You can have as many different svn client apps on a
> given system as you want, and so long as they are all using the same
> copy of our libraries, there is no cross-version compatibility problem.
What? There definitely is, specifically in the case of the working copy
library. Not on the API level, of course, but that's hardly where the
WC-version problem stems from. That's why you have GUI clients that
contain copies of several different versions of SVN's client libraries
and pick the correct one depending on the version of the working copy
they happen to be dealing with at any particular moment.
And really, there's no reason why the Subversion command-line client
shouldn't do the same thing -- in fact, this is by far the easiest way
to support multiple working copy formats, even if it is less than
optimal as far as installed binary size is concerned (not to mention
release management and version juggling and testing).
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jul 12, 2012 at 7:31 PM, Peter Samuelson <pe...@p12n.org> wrote:
> [Markus Schaber]
>> So my personal experience tells me that multiple-client scenarios are
>> the common case, and that the deployment strategy (only using linux
>> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
>> problem.
>
> So, we provide a pile of libraries that maintain ABI backward
> compatibility. You can have as many different svn client apps on a
> given system as you want, and so long as they are all using the same
> copy of our libraries, there is no cross-version compatibility problem.
>
> (Of course, there's two other related issues: 1) sharing a wc across
> two or more systems; 2) use of SVNKit. I'll ignore both for now;
> SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
I think it's sad that there is so much antagonism against SVNKit in
this community. With my svn user hat on, I consider SVNKit as just
another part of the svn ecosystem. As a user, I don't really care if
it's implemented in C, in Java or in Turbo Pascal :-), as long as it
plays by the rules and acts like any other svn client. Besides, in our
environment I have no choice but to use SVNKit: the svn plugin of my
IDE (IntelliJ IDEA) only works with SVNKit.
I think it would be beneficial for the svn ecosystem as a whole if
this community would try to build better relations with the SVNKit
people. Some mutual understanding certainly wouldn't hurt. I was very
happy to see more interest by the SVNKit guys in the core project, and
see their presence at the Berlin Hackathon (hi Dmitry :-)).
> But IMO, we need to encourage using a _single_ copy of the Subversion
> libraries for all your clients. As you noted, that's how things work
> in integrated OSes like Linux distributions. It is unfortunate that
> the Windows world has a long cultural history of bundling dependencies
> into every installer, which obviously works against this goal.
>
> Is there some way we could push back? Encourage downstream developers
> to settle on a common libsvn installation? If they have to bundle it
> for ease-of-installation purposes, can they do so in such a way that,
> from a system perspective, it's two independent components? Basically
> bundle a common libsvn _installer_, instead of bundling libsvn (and of
> course apr / apr-util / apr-iconv and their dependencies) into your
> base package?
>
> I think there's precedent for this approach - e.g., the way some
> Windows installers will bundle a copy of VC++ runtime libraries, or the
> .NET CLR, in case you don't have a new enough one already.
I guess this is theoretically possible. But as a Windows user, I
personally wouldn't like it. This is exactly one of the things that
annoys me every time when I'm working on e.g. Solaris: What? I can't
have two different svn versions installed at the same time? On my
central build server with 1000 working copies I can't just quickly
install a 1.7 version to do some tests, while all my colleagues keep
on running svn 1.6 for the real stuff. Gah.
--
Johan
Re: Format bump for 1.8?
Posted by Peter Samuelson <pe...@p12n.org>.
[Markus Schaber]
> So my personal experience tells me that multiple-client scenarios are
> the common case, and that the deployment strategy (only using linux
> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
> problem.
So, we provide a pile of libraries that maintain ABI backward
compatibility. You can have as many different svn client apps on a
given system as you want, and so long as they are all using the same
copy of our libraries, there is no cross-version compatibility problem.
(Of course, there's two other related issues: 1) sharing a wc across
two or more systems; 2) use of SVNKit. I'll ignore both for now;
SVNKit in particular is, and should be, Somebody Else's Problem anyway.)
But IMO, we need to encourage using a _single_ copy of the Subversion
libraries for all your clients. As you noted, that's how things work
in integrated OSes like Linux distributions. It is unfortunate that
the Windows world has a long cultural history of bundling dependencies
into every installer, which obviously works against this goal.
Is there some way we could push back? Encourage downstream developers
to settle on a common libsvn installation? If they have to bundle it
for ease-of-installation purposes, can they do so in such a way that,
from a system perspective, it's two independent components? Basically
bundle a common libsvn _installer_, instead of bundling libsvn (and of
course apr / apr-util / apr-iconv and their dependencies) into your
base package?
I think there's precedent for this approach - e.g., the way some
Windows installers will bundle a copy of VC++ runtime libraries, or the
.NET CLR, in case you don't have a new enough one already.
But I suppose for this to be workable, we would have to stop relying on
third parties to build our Windows installers, and actually build one
ourselves. Is this feasible?
Peter
AW: Format bump for 1.8?
Posted by Markus Schaber <m....@3s-software.com>.
Hi,
> Von: Johan Corveleyn [mailto:jcorvel@gmail.com]
> On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> > On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> >> That's true, but one of the problems I'm trying to solve here is
> >> users having different clients on their system, each with their own
> >> release cycle. Maybe one of those offers this back-compat feature (e.g.
> >> currently the one that uses svnkit under the hood), but not the other
> >> two. That problem can only be solved, I think, if the core project
> >> makes this a built-in supported feature.
> >
> > We can not, and should not attempt to, solve every problem for every
> > user. Using heterogenous versions in the same environment has a set
> > of known risks (which were somewhat alleviated by the manual upgrade
> > step in 1.7, btw). We attempt to catch and prevent old clients from
> > corrupting newer working copies, but that's as far as I think we need
> > to go.
>
> You seem to be implying that users having multiple svn clients on their
> system are the exception, rather than the rule. I think it's the other way
> around (though I haven't done the market research to back that up of
> course :-)). And all too often, regular users do *not* know the risks (but
> the manual upgrade is indeed a big help here).
Just some non-representative data from my last working environments:
Logix: We had command line svn (Debian package) and subclipse (svnkit, from eclipse.org). Some users used other graphical frontends, but they're all from the debian repository, so they used the same libs as the command line tools, effectively giving 2 different client versions.
Soloplan: Most coworkers had TortoiseSVN and AnkhSVN, and some had a command line client in addition. Giving 2 or 3 different client versions.
3S: Most coworkers have TortoiseSVN and AnkhSVN, some add a command line client, and very few ones (I'm the only one I'm aware of) use VisualSVN instead of AnkhSVN. As recent TortoiseSVN comes with the command line versions, and VisualSVN includes TortoiseSVN, this gives between 1 and 3 client versions for each user.
In all of those environments, I remember gripes about client version mismatches from coworkers which were not aware of the working copy format compatibility issue, especially when one client was upgraded with levity (aka apt-get dist-upgrade, or the tortoise "a new version is available" screen) and the other client was not yet available in that new version, because it lags behind in the upgrade cygle. This was worsened by clients like TortoiseSVN which refuse to be installed in several versions in parallel.
So my personal experience tells me that multiple-client scenarios are the common case, and that the deployment strategy (only using linux distro packages, or 3-in-1 bundles like VisualSVN) can reduce that problem.
That said, I think the core SVN project should not put too much effort into support for old working copy formats.
But we should clearly announce that an 1.X-Upgrade will need a working copy format bump, and encourage other client distributors (Tortoise, Visual, Ankh, Subclipse, ...) to do the same.
Maybe we should also encourage linux distributions to ship both versions in parallel for some time, as e. G. Debian does with GCC or PostgreSQL, and advocate parallel installability of different releases for other clients, at least as long as we cannot upgrade all existing working copies (see the "cleanup needed" issue.)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Format bump for 1.8?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jul 11, 2012 at 3:19 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>>>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>>> ...
>>>>> For instance, we could simply package two set of binaries/libraries in
>>>>> one package (the 1.8.0 version together with 1.7.x (taken from the
>>>>> corresponding tag)), and implement a main wrapper that delegates
>>>>> everything to the appropriate version. The 1.8.0 code doesn't need to
>>>>> care about the 1.7-compat stuff, we just have a dispatcher and package
>>>>> the old code together with it. I'm just fantasizing of course, for
>>>>> illustrative purposes only :-). But ... it depends. Anyone have a
>>>>> creative idea how this could technically be done and what the pros and
>>>>> cons would be?
>>>>
>>>> Or some third-party could just do this, and we wouldn't have to mess
>>>> with it at all. If there is a demand, somebody will step up and do
>>>> it, but I don't think we (as the Apache Subversion project) should too
>>>> much about it.
>>>
>>> That's true, but one of the problems I'm trying to solve here is users
>>> having different clients on their system, each with their own release
>>> cycle. Maybe one of those offers this back-compat feature (e.g.
>>> currently the one that uses svnkit under the hood), but not the other
>>> two. That problem can only be solved, I think, if the core project
>>> makes this a built-in supported feature.
>>
>> We can not, and should not attempt to, solve every problem for every
>> user. Using heterogenous versions in the same environment has a set
>> of known risks (which were somewhat alleviated by the manual upgrade
>> step in 1.7, btw). We attempt to catch and prevent old clients from
>> corrupting newer working copies, but that's as far as I think we need
>> to go.
>
> You seem to be implying that users having multiple svn clients on
> their system are the exception, rather than the rule. I think it's the
> other way around (though I haven't done the market research to back
> that up of course :-)). And all too often, regular users do *not* know
> the risks (but the manual upgrade is indeed a big help here).
>
> But I understand, we can't solve every problem on the planet (there
> needs to be some room left for educating users too :-)).
>
>> You have a different opinion, and I respect that, but the amount of
>> effort required to simultaneously support multiple active working copy
>> formats will probably prove prohibitive. Unless you are willing to
>> bear that burden yourself, it will probably be difficult convincing
>> the rest of the community that this departure from historic precedent
>> is worth the maintenance burden.
>
> I'm obviously not about to bear the burden myself, this thread was all
> about convincing you guys that this could be a burden worth bearing
> (and that maybe, with some creativity, the burden could be kept
> light).
>
> But okay, it seems I'm totally outnumbered (not a single voice of
> support in this thread). Fine. I concede.
I wasn't trying to push your opinion to the side, just pointing out
that you've a long row to hoe in trying to change the status quo. If
you feel passionate about it, by all means please continue to fight
the good fight.
(As for me, my view has now been made quite vociferously known, so I
will now fade back into the shadows.)
-Hyrum
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>> ...
>>>> For instance, we could simply package two set of binaries/libraries in
>>>> one package (the 1.8.0 version together with 1.7.x (taken from the
>>>> corresponding tag)), and implement a main wrapper that delegates
>>>> everything to the appropriate version. The 1.8.0 code doesn't need to
>>>> care about the 1.7-compat stuff, we just have a dispatcher and package
>>>> the old code together with it. I'm just fantasizing of course, for
>>>> illustrative purposes only :-). But ... it depends. Anyone have a
>>>> creative idea how this could technically be done and what the pros and
>>>> cons would be?
>>>
>>> Or some third-party could just do this, and we wouldn't have to mess
>>> with it at all. If there is a demand, somebody will step up and do
>>> it, but I don't think we (as the Apache Subversion project) should too
>>> much about it.
>>
>> That's true, but one of the problems I'm trying to solve here is users
>> having different clients on their system, each with their own release
>> cycle. Maybe one of those offers this back-compat feature (e.g.
>> currently the one that uses svnkit under the hood), but not the other
>> two. That problem can only be solved, I think, if the core project
>> makes this a built-in supported feature.
>
> We can not, and should not attempt to, solve every problem for every
> user. Using heterogenous versions in the same environment has a set
> of known risks (which were somewhat alleviated by the manual upgrade
> step in 1.7, btw). We attempt to catch and prevent old clients from
> corrupting newer working copies, but that's as far as I think we need
> to go.
You seem to be implying that users having multiple svn clients on
their system are the exception, rather than the rule. I think it's the
other way around (though I haven't done the market research to back
that up of course :-)). And all too often, regular users do *not* know
the risks (but the manual upgrade is indeed a big help here).
But I understand, we can't solve every problem on the planet (there
needs to be some room left for educating users too :-)).
> You have a different opinion, and I respect that, but the amount of
> effort required to simultaneously support multiple active working copy
> formats will probably prove prohibitive. Unless you are willing to
> bear that burden yourself, it will probably be difficult convincing
> the rest of the community that this departure from historic precedent
> is worth the maintenance burden.
I'm obviously not about to bear the burden myself, this thread was all
about convincing you guys that this could be a burden worth bearing
(and that maybe, with some creativity, the burden could be kept
light).
But okay, it seems I'm totally outnumbered (not a single voice of
support in this thread). Fine. I concede.
--
Johan
Re: Format bump for 1.8?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> ...
>>> For instance, we could simply package two set of binaries/libraries in
>>> one package (the 1.8.0 version together with 1.7.x (taken from the
>>> corresponding tag)), and implement a main wrapper that delegates
>>> everything to the appropriate version. The 1.8.0 code doesn't need to
>>> care about the 1.7-compat stuff, we just have a dispatcher and package
>>> the old code together with it. I'm just fantasizing of course, for
>>> illustrative purposes only :-). But ... it depends. Anyone have a
>>> creative idea how this could technically be done and what the pros and
>>> cons would be?
>>
>> Or some third-party could just do this, and we wouldn't have to mess
>> with it at all. If there is a demand, somebody will step up and do
>> it, but I don't think we (as the Apache Subversion project) should too
>> much about it.
>
> That's true, but one of the problems I'm trying to solve here is users
> having different clients on their system, each with their own release
> cycle. Maybe one of those offers this back-compat feature (e.g.
> currently the one that uses svnkit under the hood), but not the other
> two. That problem can only be solved, I think, if the core project
> makes this a built-in supported feature.
We can not, and should not attempt to, solve every problem for every
user. Using heterogenous versions in the same environment has a set
of known risks (which were somewhat alleviated by the manual upgrade
step in 1.7, btw). We attempt to catch and prevent old clients from
corrupting newer working copies, but that's as far as I think we need
to go.
You have a different opinion, and I respect that, but the amount of
effort required to simultaneously support multiple active working copy
formats will probably prove prohibitive. Unless you are willing to
bear that burden yourself, it will probably be difficult convincing
the rest of the community that this departure from historic precedent
is worth the maintenance burden.
-Hyrum
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> ...
>> For instance, we could simply package two set of binaries/libraries in
>> one package (the 1.8.0 version together with 1.7.x (taken from the
>> corresponding tag)), and implement a main wrapper that delegates
>> everything to the appropriate version. The 1.8.0 code doesn't need to
>> care about the 1.7-compat stuff, we just have a dispatcher and package
>> the old code together with it. I'm just fantasizing of course, for
>> illustrative purposes only :-). But ... it depends. Anyone have a
>> creative idea how this could technically be done and what the pros and
>> cons would be?
>
> Or some third-party could just do this, and we wouldn't have to mess
> with it at all. If there is a demand, somebody will step up and do
> it, but I don't think we (as the Apache Subversion project) should too
> much about it.
That's true, but one of the problems I'm trying to solve here is users
having different clients on their system, each with their own release
cycle. Maybe one of those offers this back-compat feature (e.g.
currently the one that uses svnkit under the hood), but not the other
two. That problem can only be solved, I think, if the core project
makes this a built-in supported feature.
--
Johan
Re: Format bump for 1.8?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> ...
> For instance, we could simply package two set of binaries/libraries in
> one package (the 1.8.0 version together with 1.7.x (taken from the
> corresponding tag)), and implement a main wrapper that delegates
> everything to the appropriate version. The 1.8.0 code doesn't need to
> care about the 1.7-compat stuff, we just have a dispatcher and package
> the old code together with it. I'm just fantasizing of course, for
> illustrative purposes only :-). But ... it depends. Anyone have a
> creative idea how this could technically be done and what the pros and
> cons would be?
Or some third-party could just do this, and we wouldn't have to mess
with it at all. If there is a demand, somebody will step up and do
it, but I don't think we (as the Apache Subversion project) should too
much about it.
-Hyrum
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 11, 2012 at 5:29 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cm...@collab.net>
>> wrote:
>> ...
>> > That said, I'm not really in favor of us maintaining multiple codepaths
>> > (based on WC version) in the client. I just don't see the cost
>> > justifying
>> > the benefit. I mean, it makes sense to do so in the repositories as we
>> > do
>> > today, because the cost of any Subversion upgrade could be equivalent to
>> > the
>> > cost of a full dump/load of the repository. I think that's too much to
>> > ask
>> > of our administrators. But for working copies?
>>
>>
>> On Wed, Jul 11, 2012 at 4:27 PM, Mark Phippard <ma...@gmail.com> wrote:
>> ...
>> > We have always had a problem delivering new features as fast as our
>> > users
>> > want to see them, I would hate to see us adopt new policies that just
>> > make
>> > it harder for us to turn the crank on new releases and new features. I
>> > would be against trying to support multiple formats for this reason.
>>
>> Hmz. The fact that we don't deliver features as fast as our users want
>> is mainly a resources vs. effort issue. But this doesn't seem that
>> much different from any other "feature" to me (of course there is a
>> cost in developing the framework/infrastructure/... to support older
>> working copy formats). But maybe you're talking about a recurring
>> increase in effort for every release from now on.
>>
> I think the effort would be enormous. As one example, we would need to
> figure out how to make our test suite test it and then ideally we would all
> run those tests with each change. Any time someone makes a change involving
> the WC they need to factor this in. I think it creates a fairly significant
> burden on almost every change that we make.
Concerning test effort, I think we can be pragmatic, and just not test
this systematically. Similar to how we currently support 1.7-server
with 1.x format repositories. I mean, does anyone systematically test
our 1.7.x release candidates with a 1.6 or 1.5 repository? The same
with our client-server compatibility: do we systematically test 1.7
clients with 1.6 or 1.0 servers? No, we might test those if someone
reports a specific issue, but other than that it's best effort ...
Concerning developers having to take this into account all the time:
yes that's true. They/we need to be aware of it and be careful not to
break the N-1-compat code. But how hard that is will depend on how we
implement this "feature".
For instance, we could simply package two set of binaries/libraries in
one package (the 1.8.0 version together with 1.7.x (taken from the
corresponding tag)), and implement a main wrapper that delegates
everything to the appropriate version. The 1.8.0 code doesn't need to
care about the 1.7-compat stuff, we just have a dispatcher and package
the old code together with it. I'm just fantasizing of course, for
illustrative purposes only :-). But ... it depends. Anyone have a
creative idea how this could technically be done and what the pros and
cons would be?
--
Johan
Re: Format bump for 1.8?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cm...@collab.net>
> wrote:
> ...
> > That said, I'm not really in favor of us maintaining multiple codepaths
> > (based on WC version) in the client. I just don't see the cost
> justifying
> > the benefit. I mean, it makes sense to do so in the repositories as we
> do
> > today, because the cost of any Subversion upgrade could be equivalent to
> the
> > cost of a full dump/load of the repository. I think that's too much to
> ask
> > of our administrators. But for working copies?
>
>
> On Wed, Jul 11, 2012 at 4:27 PM, Mark Phippard <ma...@gmail.com> wrote:
> ...
> > We have always had a problem delivering new features as fast as our users
> > want to see them, I would hate to see us adopt new policies that just
> make
> > it harder for us to turn the crank on new releases and new features. I
> > would be against trying to support multiple formats for this reason.
>
> Hmz. The fact that we don't deliver features as fast as our users want
> is mainly a resources vs. effort issue. But this doesn't seem that
> much different from any other "feature" to me (of course there is a
> cost in developing the framework/infrastructure/... to support older
> working copy formats). But maybe you're talking about a recurring
> increase in effort for every release from now on.
>
> I think the effort would be enormous. As one example, we would need to
figure out how to make our test suite test it and then ideally we would all
run those tests with each change. Any time someone makes a change
involving the WC they need to factor this in. I think it creates a fairly
significant burden on almost every change that we make.
I guess I could be wrong, but that is how it seems to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Format bump for 1.8?
Posted by Johan Corveleyn <jc...@gmail.com>.
On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cm...@collab.net> wrote:
...
> That said, I'm not really in favor of us maintaining multiple codepaths
> (based on WC version) in the client. I just don't see the cost justifying
> the benefit. I mean, it makes sense to do so in the repositories as we do
> today, because the cost of any Subversion upgrade could be equivalent to the
> cost of a full dump/load of the repository. I think that's too much to ask
> of our administrators. But for working copies?
On Wed, Jul 11, 2012 at 4:27 PM, Mark Phippard <ma...@gmail.com> wrote:
...
> We have always had a problem delivering new features as fast as our users
> want to see them, I would hate to see us adopt new policies that just make
> it harder for us to turn the crank on new releases and new features. I
> would be against trying to support multiple formats for this reason.
Hmz. The fact that we don't deliver features as fast as our users want
is mainly a resources vs. effort issue. But this doesn't seem that
much different from any other "feature" to me (of course there is a
cost in developing the framework/infrastructure/... to support older
working copy formats). But maybe you're talking about a recurring
increase in effort for every release from now on.
Maybe we can scope the feature a bit to reduce the (recurring) effort:
1) We only support format N-1, so only the immediately previous version.
2) We only support it in the same way as we currently support client
version N-1 (only security / data-corruption bugfixes ...).
We have to maintain version N-1 of the software anyway, so for a
little extra overhead we can maybe also support the
client(N)-workingcopy(N-1) variant.
I think this would be a great benefit to our users, especially in
enterprise environments. It avoids the "big bang" moment for users
(like me and a lot of my colleagues) where you currently have to
coordinate the upgrade of your 3 clients and 100 working copies into
one single moment in time, to make sure you can keep on working.
I just had a chat about this with a colleague, and he also commented:
"the least they can do is support the previous working copy format
(only that one), so my environment doesn't break immediately after
upgrading one client".
Is there really no creative way to do this? We support all our old
public API's (deprecated) into eternity...
Right now, I'm into the habit of keeping around my previous svn
(commandline) client installed on my machine, and I rename svn.exe to
svn-1.6.exe (and keep it in my PATH). Whenever I have to do something
with an older working copy, I just call svn-1.6.exe and do my thing
(after first running svn.exe, and encountering the "please upgrade"
error of course :-)). Why can't the client do that dispatching for me?
--
Johan
Re: Format bump for 1.8?
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jul 11, 2012 at 7:23 AM, C. Michael Pilato <cm...@collab.net>wrote:
> I actually feel like the 1.7 situation was the best we've had to date:
> restrictive WC format client support, an explicit upgrade step, minimal
> surprises.
>
Agreed. I think the only problem with the 1.7 upgrade was that it was the
first time the process was really lengthy. That is not likely to be an
issue with future upgrade of the format.
We have always had a problem delivering new features as fast as our users
want to see them, I would hate to see us adopt new policies that just make
it harder for us to turn the crank on new releases and new features. I
would be against trying to support multiple formats for this reason.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Format bump for 1.8?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/11/2012 09:50 AM, Johan Corveleyn wrote:
> Yes, I agree we'd have to make it clear in our docs that feature X
> depends on working copy format Y. That's an additional effort, yes.
> But for the book or the FAQ it's not a lot different from phrases
> where they now say: "If you've got Subversion 1.7 or higher, you'll
> get ...". Then they'll have to say "If your working copy format is 1.8
> or higher, you'll get ...".
Documentation-wise, I don't see this as much more problematic than "If
you're server was created with Subversion 1.5 or better, the mergeinfo
feature is available."
> As I said elsethread, most end-users I know consider the "manual
> upgrade" in 1.7 a clear improvement over auto-upgrading. It makes the
> entire process less scary. It avoids accidents like the scenario I
> mentioned, where the user has 3 svn clients (a commandline client, a
> GUI tool, and an IDE plugin), which all have their own release cycles.
> In that situation, an auto-upgrade by one of the three, while another
> can't be upgraded immediatly, can wreak havoc. It's much better to
> error out with 'working copy format too old, run svn upgrade'.
Agreed. Working copy auto-upgrade has been a repeated point of concern by
our users over the years, for the scenario you gave as well as for the
situation where users share working copies. (A similar situation drives the
reason why we don't auto-upgrade repositories -- multiple users hitting a
repository over ra_local with different client versions.)
That said, I'm not really in favor of us maintaining multiple codepaths
(based on WC version) in the client. I just don't see the cost justifying
the benefit. I mean, it makes sense to do so in the repositories as we do
today, because the cost of any Subversion upgrade could be equivalent to the
cost of a full dump/load of the repository. I think that's too much to ask
of our administrators. But for working copies?
I actually feel like the 1.7 situation was the best we've had to date:
restrictive WC format client support, an explicit upgrade step, minimal
surprises.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development