You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/04/30 18:02:52 UTC
[PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Looking over the responses to the roadmap proposal, I think they can
mostly be summarized as: "Do atomic renames sooner!" :-)
I feel strongly that trying to put "atomic renames" all in one
milestone would be a mistake. As even the preliminary discussions
have shown, it is not a trivial problem.
The key (ironically enough, I guess) is to break atomic renames up
into discrete subtasks as much as we can. Fortunately, there's an
obvious place to start: implement atomic renames in the repository.
We wouldn't worry about the working copy at first. It would still
receive renames as it currently does, and the only gateway to the new
functionality would be 'svn mv URL1 URL2'. But it would be an
important first step and -- obviously, IMHO -- a prerequisite for
further atomic rename functionality.
(This is essentially what issue #898 is now, I think, although #898
did not start out that way.)
So below is a new proposal, similar to the previous one, but starting
the renames work much sooner -- the first piece would happen in 1.3.
1.3: Server->client configuration transmission.
Just repository side of atomic renames.
ETA for 1.3: Sep. 1 (assumes first soak starts June 15th or so)
User-visible features resulting from config transmission:
* Log message templates (note: this is a CVS parity issue!)
* Improved (server-driven) mime-type assignments.
* Various other settings TBD.
User-visible features resulting from repos-side atomic renames:
TBD. This may turn out be mainly infrastructure work,
though possibly the output of 'svn log -v' (for example)
could show renames more definitively, if the rename was done
with 'svn mv URL1 URL2'.
1.4: Operation logging.
ETA for 1.4: Jan. 1 (assumes first soak starts Nov 15th or so)
"What's operation logging?" I hear you ask.
This is also a CVS parity issue. There is currently not even
any configuration option to get Subversion to consistently
record read-only operations, similar to the CVSROOT/history
file used by the 'cvs history' command. Even Apache w/
mod_dav_svn, the httpd logs do not enable us to distinguish
between checkout/update/switch/blame/log/diff/merge. You can
never be sure what you're looking at. And that's the RA layer
with the most thorough recording! :-)
We need a consistent logging system that all RA layers can
use, that will collect information from a Subversion point of
view, not an "HTTP GET" point of view. This also requires a
design discussion, but probably not a huge one. We just need
to decide what we want to record, and the format in which we
want to record it. No rocket science here. (Correction: Ben
just informed me that it *is* rocket science, because there's
a debate about whether or not to involve the native OS logging
system. Fine. We'll cross that bridge when we come to it.)
Part of the goal of this milestone is to be Not Too Hard.
Operation logging is not a new feature on the scale of
server->client configurations, or even repos-side atomic
renames. But that's okay! In fact, it might be nice to do
some bugfix-only releases from time to time. We don't have to
add a new feature with every release. Operation logging is
sort of a halfway step between those two strategies.
1.5: TBD, see below
ETA for 1.5: TBD (depends on what's in it)
1.5 open for discussion, but I imagine that we'd want to
continue with renames, including the working copy side.
Thoughts on this new proposal?
I'm trying to not get into design details in this thread. It should
be about high-level overview.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > 1.3: Server->client configuration transmission.
> > Just repository side of atomic renames.
> >
> > ETA for 1.3: Sep. 1 (assumes first soak starts June 15th or so)
>
> I'm fine with this proposal. I think ETA for 1.3 is a bit optimistic,
> though. It means designing and implementing these in 1.5 months. Of
> course it depends on how much resources we have.
It's optimistic, though it's not beyond the bounds of possibility.
Let's agree now that if one of the features is done but not the other,
that instead of holding up the release, we'll just move the lagging
feature to 1.4 and shift everything else up one release.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 30 Apr 2005 kfogel@collab.net wrote:
> 1.3: Server->client configuration transmission.
> Just repository side of atomic renames.
>
> ETA for 1.3: Sep. 1 (assumes first soak starts June 15th or so)
>
I'm fine with this proposal. I think ETA for 1.3 is a bit optimistic,
though. It means designing and implementing these in 1.5 months. Of
course it depends on how much resources we have.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by Branko Čibej <br...@xbc.nu>.
Peter McNab wrote:
> What about NT4.0 then?
> Might get some votes from MS if you wack in some code that NT can't
> support.
NT4 is a passably acceptable system. We do have some code in SVN that
won't work on NT4, but it's conditional at runtime.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by Peter McNab <mc...@melbpc.org.au>.
Branko Čibej wrote:
> kfogel@collab.net wrote:
>
>> Looking over the responses to the roadmap proposal, I think they can
>> mostly be summarized as: "Do atomic renames sooner!" :-)
>>
>>
> Yes.
>
> Now I'd like to propose that we put something else on our roadmap. Not
> a feature at all. It's more like preventive therapy for retaining (at
> least my) sanity.
>
> As far as I know, the last of the DOS-based Windows variants (Windoes
> 98/Me) are close to being dead as far as Microsoft is concerned. They
> do promis some kind of pay-per-incident support and security hot-fixes
> until mid-2006, but that's about it.
>
> So I propose we a) change our FAQ (which currently has things to say
> about FSFS on Win98) to say that we do not support any kind of
> Subversion repository on those systems, and b) stop supporting
> Subversion at all on those systems once MS pulls the plug (that would
> coincide with our 1.5 or possibly 1.6).
>
> Unless, of course, somebody steps up and promises to test and fix bugs
> on those platforms.
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
What about NT4.0 then?
Might get some votes from MS if you wack in some code that NT can't
support.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Looking over the responses to the roadmap proposal, I think they can
>mostly be summarized as: "Do atomic renames sooner!" :-)
>
>
Yes.
Now I'd like to propose that we put something else on our roadmap. Not a
feature at all. It's more like preventive therapy for retaining (at
least my) sanity.
As far as I know, the last of the DOS-based Windows variants (Windoes
98/Me) are close to being dead as far as Microsoft is concerned. They do
promis some kind of pay-per-incident support and security hot-fixes
until mid-2006, but that's about it.
So I propose we a) change our FAQ (which currently has things to say
about FSFS on Win98) to say that we do not support any kind of
Subversion repository on those systems, and b) stop supporting
Subversion at all on those systems once MS pulls the plug (that would
coincide with our 1.5 or possibly 1.6).
Unless, of course, somebody steps up and promises to test and fix bugs
on those platforms.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by kf...@collab.net.
Erik Huelsmann <eh...@gmail.com> writes:
> What you see here is a often requested feature which IMO comes from a
> much larger issue. I think we should do an interim release to clean
> out the issue tracker. No glorious new features, just bugfixes. This
> release should address the rename problem, schedule-add-with-history
> and a few others which can seriously mess up day-to-day work with svn.
> Surely, if 1.3 were to be that release, it will include neon 0.25
> too.
Well, calling something a "new feature" versus a "bugfix" doesn't
change its size. Have you looked closely at the rename problem? :-)
It is larger and more complex than any of the new features we've been
contemplating. Putting it on a list with other bugfixes is like
putting Australia on a list with other islands.
(Unless by "the rename problem" you just mean the minimal
repository-side bit I was talking about in my last mail, the bit that
is now represented by issue #898?)
In principle I'm all for a bugfix-only release. But we still have
some CVS parity to achieve: log message templates and better
server-side logging are areas where we have failed to match CVS.
It's not just academic: people ask about the former on the users@ list
all the time, and CollabNet's customers -- who are a different
demographic than the users@ list, but no less legitimate a source of
usage data -- ask about both. That's why I want to get those features
in 1.3 and 1.4. If 1.5 is then a bugfixes-only release, that's fine.
At least we wouldn't be lagging behind CVS in any significant way at
that point. (This is assuming that the rename work is spread across
all these releases, by the way.)
Have I convinced you? :-)
I'm all for getting Neon 0.25 into 1.3, by the way, but that doesn't
mean that 1.3 must necessarily take advantage of everything Neon 0.25
offers.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by Erik Huelsmann <eh...@gmail.com>.
On 30 Apr 2005 13:02:52 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> Looking over the responses to the roadmap proposal, I think they can
> mostly be summarized as: "Do atomic renames sooner!" :-)
>
> I feel strongly that trying to put "atomic renames" all in one
> milestone would be a mistake. As even the preliminary discussions
> have shown, it is not a trivial problem.
>
> The key (ironically enough, I guess) is to break atomic renames up
> into discrete subtasks as much as we can. Fortunately, there's an
> obvious place to start: implement atomic renames in the repository.
> We wouldn't worry about the working copy at first. It would still
> receive renames as it currently does, and the only gateway to the new
> functionality would be 'svn mv URL1 URL2'. But it would be an
> important first step and -- obviously, IMHO -- a prerequisite for
> further atomic rename functionality.
>
> (This is essentially what issue #898 is now, I think, although #898
> did not start out that way.)
>
> So below is a new proposal, similar to the previous one, but starting
> the renames work much sooner -- the first piece would happen in 1.3.
What you see here is a often requested feature which IMO comes from a
much larger issue. I think we should do an interim release to clean
out the issue tracker. No glorious new features, just bugfixes. This
release should address the rename problem, schedule-add-with-history
and a few others which can seriously mess up day-to-day work with svn.
Surely, if 1.3 were to be that release, it will include neon 0.25
too.
What do you think?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by kf...@collab.net.
SteveKing <st...@gmx.ch> writes:
> And AFAIK the interruptability uses the same callbacks which are
> needed for progress information...
Hmm, I know from looking closely before that interruptability was
really not possible with Neon < 0.25.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by SteveKing <st...@gmx.ch>.
kfogel@collab.net wrote:
> steveking <st...@gmx.ch> writes:
>
>>Sorry to comment on this so late. I hope it's not *too* late yet.
>>
>>Since neon 0.25 is now out and most likely will be included in 1.3 I'd
>>like to add another feature I've been waiting for for a long time now:
>>progress information *during* longer operations.
>>
>>Now that Subversion has locking, that will attract even more users,
>>and those users will have many binary files. And binary files can be
>>very big. So, it's really a bad user impression if they e.g. 'svn cat'
>>a binary file, but can't even see that something is going on until the
>>operation is finished. Users are used to see progress information from
>>webbrowsers (and that's something everyone is familliar with).
>>I guess you would complain too if your webbrowser wouldn't show you
>>information about a file you're downloading (like 20kB/s, 45%
>>complete).
>>
>>See http://subversion.tigris.org/issues/show_bug.cgi?id=901
>>
>>I think every GUI client out there will profit from that.
>
>
> Does Neon 0.25 make this easier? I haven't studied it in detail yet;
> all I know is that it will allow us to fix our interruptability
> problem (in other words, ^C will finally work at any point!). In my
> mind, that's more important than progress reporting, although progress
> reporting is also important.
It won't make it easier. But AFAIK, neon 0.25 changed (a littel bit) the
callback functions which would be used for that. So I didn't say
anything while neon 0.24.x was still used because it would have meant to
change the whole stuff again when 0.25 came out.
And AFAIK the interruptability uses the same callbacks which are needed
for progress information...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by kf...@collab.net.
steveking <st...@gmx.ch> writes:
> Sorry to comment on this so late. I hope it's not *too* late yet.
>
> Since neon 0.25 is now out and most likely will be included in 1.3 I'd
> like to add another feature I've been waiting for for a long time now:
> progress information *during* longer operations.
>
> Now that Subversion has locking, that will attract even more users,
> and those users will have many binary files. And binary files can be
> very big. So, it's really a bad user impression if they e.g. 'svn cat'
> a binary file, but can't even see that something is going on until the
> operation is finished. Users are used to see progress information from
> webbrowsers (and that's something everyone is familliar with).
> I guess you would complain too if your webbrowser wouldn't show you
> information about a file you're downloading (like 20kB/s, 45%
> complete).
>
> See http://subversion.tigris.org/issues/show_bug.cgi?id=901
>
> I think every GUI client out there will profit from that.
Does Neon 0.25 make this easier? I haven't studied it in detail yet;
all I know is that it will allow us to fix our interruptability
problem (in other words, ^C will finally work at any point!). In my
mind, that's more important than progress reporting, although progress
reporting is also important.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.
Posted by steveking <st...@gmx.ch>.
kfogel@collab.net wrote:
> Looking over the responses to the roadmap proposal, I think they can
> mostly be summarized as: "Do atomic renames sooner!" :-)
Sorry to comment on this so late. I hope it's not *too* late yet.
Since neon 0.25 is now out and most likely will be included in 1.3 I'd
like to add another feature I've been waiting for for a long time now:
progress information *during* longer operations.
Now that Subversion has locking, that will attract even more users, and
those users will have many binary files. And binary files can be very
big. So, it's really a bad user impression if they e.g. 'svn cat' a
binary file, but can't even see that something is going on until the
operation is finished. Users are used to see progress information from
webbrowsers (and that's something everyone is familliar with).
I guess you would complain too if your webbrowser wouldn't show you
information about a file you're downloading (like 20kB/s, 45% complete).
See http://subversion.tigris.org/issues/show_bug.cgi?id=901
I think every GUI client out there will profit from that.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org