You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2007/09/09 20:52:47 UTC
SVN 1.5 Status Update
I thought I'd try to give at least weekly updates to keep everyone
informed of the progress towards the first 1.5 release candidate. I
know not everyone is able to follow what is going on 24/7 so figured
it would be helpful for keeping everyone in the loop.
It was a pretty good week last week, if we keep this up we should be
able to meet our October 12th goal.
There were 9 issues with the 1.5 milestone closed last week. There
was also a lot of other activity last week that was not related to
issues in the tracker. Everyone was very busy. I'll try to give some
highlights. I apologize if I leave anyone out. If you take a look at
how much has been done in the last week you will see it is easy to
miss something.
Dan closed out the WC to WC copy issue (2822). That was significant
because it has been occupying a lot of his time, and driving him nuts,
over the last several weeks. So hopefully that will free him up to
tackle some other tasks in the list.
Paul finished off the various tasks related to non-inheritable merge
info and has taken on issue 2818 which is about providing an API for
merging arbitrary revision ranges.
Kamesh is still working on the new merge algorithm (2821) proposed by
Peter Lundblad earlier this year. He has found a few unrelated bugs
in merge that have sidetracked him while they are fixed. It looks
like the last of those was just committed though (r26499).
Karl seems to have a good handle on the sparse-directories work and
closed off several issues last week. It looks like Vlad continues to
help finish up this feature as well.
Lieven and Ivan have been resolving issues related to ra_serf. It
looks like Buildbot is down to 3 failures. I believe they have been
removing abort()'s in the process.
Erik continues to refactor and optimize the WC code. It looks like he
also resolved a couple of other issues from the tracker.
Hyrum is still improving the new log/blame -g options. He improved
the code for fetching merged revisions to make it streamy like the
rest of log. And he also modified the blame -g output to indicate
lines that were the result of a merge.
CMike also fixed a few issues and has started to look at some of the
new merge-related audit API's we need (2820).
Ben merged his copy-on-update branch to trunk. I am still trying to
sort out what that means exactly. It looks like right now he put some
code in place that will allow us to now work on making update smarter.
In other words, right now, things work the same but there are some
new API's available to be used that will be needed in doing this.
If you have been following the mailing list, the svn patch branch is
also getting ready to merge to trunk.
There are still 31 open issues with the 1.5 milestone. That includes
a couple of "umbrella issues".
The "big ones" in terms of new features are all related to merge
tracking with the new merge algorithm Kamesh is working on probably
the biggest.
Issue 2875 is about adding an option to svnadmin load to have it
create mergeinfo as part of doing copies. That seems like a big one
(effort-wise) and seems like it would be nice for helping people
migrate.
Issue 695 about making svn checkout -N work would be a nice one to
close. Obviously the sparse directories feature is addressing this
issue. The last time I tried to test it to see if I could close it
there were still some problems though. I might just try again with a
HEAD build.
There are some seemingly easy tasks out there for someone that wants
to just help us make progress:
2859: svn status --xml broken if user has changelists
2880: commit --changelist NO_SUCH_CHANGELIST should error
Dan reported an issue on IRC that it looks like he did not enter. He
could not commit a changelist because a file not in the changelist had
conflicts. Do we allow you to commit a named file if some other file
has conflicts? I assume so.
One we might need to push to a new release if no one steps forward:
2238: svn propset/del/edit does not support URL argument
Finally issue 2800 is about reconsidering our library renaming for
neon. It seems like we should come to some closure on this issue
soon.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by Marc Haisenko <ha...@comdasys.com>.
Thank you for the summary, that's much appreciated :-)
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Straße 7
D-80686 München
Tel: +49 (0)89 - 548 433 321
e-mail: haisenko@comdasys.com
http://www.comdasys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by David Glasser <gl...@davidglasser.net>.
On 9/12/07, Daniel Rall <dl...@finemaltcoding.com> wrote:
>
> On Sep 11, 2007, at 5:44 AM, C. Michael Pilato wrote:
>
> > David Glasser wrote:
> >> On 9/10/07, C. Michael Pilato <cm...@collab.net> wrote:
> >>> Ben Collins-Sussman wrote:
> >>>>> One we might need to push to a new release if no one steps
> >>>>> forward:
> >>>>>
> >>>>> 2238: svn propset/del/edit does not support URL argument
> >>>>>
> >>>> Argh, are we *still* debating this issue? We already added 'svn
> >>>> propedit URL' support. I suppose I can understand adding 'svn
> >>>> propdel
> >>>> URL' support (since we already support 'svn rm URL')... but I'm
> >>>> really
> >>>> against 'svn propset URL', and the issue claims there's still no
> >>>> consensus on that. I guess we should at least update the issue's
> >>>> summary.
> >>> Just out of curiousity -- what happens when you use 'svn propedit
> >>> URL' to
> >>> set svn:eol-style to, say, 'CRLF'? IIRC, the Subversion client
> >>> would
> >>> usually normalize the working file to RNF in this case, but
> >>> (obviously)
> >>> doesn't have the opportunity to do so in this URL-based propedit
> >>> case.
> >>
> >> Erk. I did make sure to keep the validation code working (ie, the
> >> propedit will fail if the EOL style is completely inconsistent),
> >> but I
> >> don't think I made it change the text. This is probably broken,
> >> then.
> >
> > Yeah, I followed up in IRC with what happens. It's a little weird.
> > Basically, the next time folks update their working copies, it
> > seems to be
> > no big deal. The file whose props were changed is reset to have
> > the right
> > line-ending style and everything, but the file shows no diffs or
> > interesting
> > status. However, if you then change anything in that file,
> > suddenly the
> > whole thing becomes a massive line-ending replacement diff. That
> > means if
> > two people happen to work on the file simultaneously, the loser of the
> > commit race will get a whole-file conflict region. :-(
>
> David, would you file an issue for this problem so that we have it in
> the tracker?
Done: #2923.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Sep 11, 2007, at 5:44 AM, C. Michael Pilato wrote:
> David Glasser wrote:
>> On 9/10/07, C. Michael Pilato <cm...@collab.net> wrote:
>>> Ben Collins-Sussman wrote:
>>>>> One we might need to push to a new release if no one steps
>>>>> forward:
>>>>>
>>>>> 2238: svn propset/del/edit does not support URL argument
>>>>>
>>>> Argh, are we *still* debating this issue? We already added 'svn
>>>> propedit URL' support. I suppose I can understand adding 'svn
>>>> propdel
>>>> URL' support (since we already support 'svn rm URL')... but I'm
>>>> really
>>>> against 'svn propset URL', and the issue claims there's still no
>>>> consensus on that. I guess we should at least update the issue's
>>>> summary.
>>> Just out of curiousity -- what happens when you use 'svn propedit
>>> URL' to
>>> set svn:eol-style to, say, 'CRLF'? IIRC, the Subversion client
>>> would
>>> usually normalize the working file to RNF in this case, but
>>> (obviously)
>>> doesn't have the opportunity to do so in this URL-based propedit
>>> case.
>>
>> Erk. I did make sure to keep the validation code working (ie, the
>> propedit will fail if the EOL style is completely inconsistent),
>> but I
>> don't think I made it change the text. This is probably broken,
>> then.
>
> Yeah, I followed up in IRC with what happens. It's a little weird.
> Basically, the next time folks update their working copies, it
> seems to be
> no big deal. The file whose props were changed is reset to have
> the right
> line-ending style and everything, but the file shows no diffs or
> interesting
> status. However, if you then change anything in that file,
> suddenly the
> whole thing becomes a massive line-ending replacement diff. That
> means if
> two people happen to work on the file simultaneously, the loser of the
> commit race will get a whole-file conflict region. :-(
David, would you file an issue for this problem so that we have it in
the tracker?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On 9/10/07, C. Michael Pilato <cm...@collab.net> wrote:
>> Ben Collins-Sussman wrote:
>>>> One we might need to push to a new release if no one steps forward:
>>>>
>>>> 2238: svn propset/del/edit does not support URL argument
>>>>
>>> Argh, are we *still* debating this issue? We already added 'svn
>>> propedit URL' support. I suppose I can understand adding 'svn propdel
>>> URL' support (since we already support 'svn rm URL')... but I'm really
>>> against 'svn propset URL', and the issue claims there's still no
>>> consensus on that. I guess we should at least update the issue's
>>> summary.
>> Just out of curiousity -- what happens when you use 'svn propedit URL' to
>> set svn:eol-style to, say, 'CRLF'? IIRC, the Subversion client would
>> usually normalize the working file to RNF in this case, but (obviously)
>> doesn't have the opportunity to do so in this URL-based propedit case.
>
> Erk. I did make sure to keep the validation code working (ie, the
> propedit will fail if the EOL style is completely inconsistent), but I
> don't think I made it change the text. This is probably broken, then.
Yeah, I followed up in IRC with what happens. It's a little weird.
Basically, the next time folks update their working copies, it seems to be
no big deal. The file whose props were changed is reset to have the right
line-ending style and everything, but the file shows no diffs or interesting
status. However, if you then change anything in that file, suddenly the
whole thing becomes a massive line-ending replacement diff. That means if
two people happen to work on the file simultaneously, the loser of the
commit race will get a whole-file conflict region. :-(
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVN 1.5 Status Update
Posted by David Glasser <gl...@davidglasser.net>.
On 9/10/07, C. Michael Pilato <cm...@collab.net> wrote:
> Ben Collins-Sussman wrote:
> >> One we might need to push to a new release if no one steps forward:
> >>
> >> 2238: svn propset/del/edit does not support URL argument
> >>
> >
> > Argh, are we *still* debating this issue? We already added 'svn
> > propedit URL' support. I suppose I can understand adding 'svn propdel
> > URL' support (since we already support 'svn rm URL')... but I'm really
> > against 'svn propset URL', and the issue claims there's still no
> > consensus on that. I guess we should at least update the issue's
> > summary.
>
> Just out of curiousity -- what happens when you use 'svn propedit URL' to
> set svn:eol-style to, say, 'CRLF'? IIRC, the Subversion client would
> usually normalize the working file to RNF in this case, but (obviously)
> doesn't have the opportunity to do so in this URL-based propedit case.
Erk. I did make sure to keep the validation code working (ie, the
propedit will fail if the EOL style is completely inconsistent), but I
don't think I made it change the text. This is probably broken, then.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman wrote:
>> One we might need to push to a new release if no one steps forward:
>>
>> 2238: svn propset/del/edit does not support URL argument
>>
>
> Argh, are we *still* debating this issue? We already added 'svn
> propedit URL' support. I suppose I can understand adding 'svn propdel
> URL' support (since we already support 'svn rm URL')... but I'm really
> against 'svn propset URL', and the issue claims there's still no
> consensus on that. I guess we should at least update the issue's
> summary.
Just out of curiousity -- what happens when you use 'svn propedit URL' to
set svn:eol-style to, say, 'CRLF'? IIRC, the Subversion client would
usually normalize the working file to RNF in this case, but (obviously)
doesn't have the opportunity to do so in this URL-based propedit case.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVN 1.5 Status Update
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Sep 11, 2007, at 2:21 AM, Daniel Rall wrote:
>
> On Sep 10, 2007, at 8:03 AM, Ben Collins-Sussman wrote:
>
>> On 9/9/07, Mark Phippard <ma...@gmail.com> wrote:
>> ...
>>> Dan reported an issue on IRC that it looks like he did not
>>> enter. He
>>> could not commit a changelist because a file not in the
>>> changelist had
>>> conflicts.
>>
>> Doh, that sounds like a stupid bug just begging for a test-case!
>
> I added a basic 'svn ci --changelist' test today to
> commit_tests.py, with the intent of morphing it to test this
> conflict buglet.
I committed a fix for this bug -- and corresponding test suite change
-- today in r26568.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Sep 10, 2007, at 8:03 AM, Ben Collins-Sussman wrote:
> On 9/9/07, Mark Phippard <ma...@gmail.com> wrote:
> ...
>> Dan reported an issue on IRC that it looks like he did not enter. He
>> could not commit a changelist because a file not in the changelist
>> had
>> conflicts.
>
> Doh, that sounds like a stupid bug just begging for a test-case!
I added a basic 'svn ci --changelist' test today to commit_tests.py,
with the intent of morphing it to test this conflict buglet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by Mark Phippard <ma...@gmail.com>.
On 9/10/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/9/07, Mark Phippard <ma...@gmail.com> wrote:
>
> > Kamesh is still working on the new merge algorithm (2821) proposed by
> > Peter Lundblad earlier this year.
>
> Wow, Kamesh is a super-hero! :-)
>
> > Ben merged his copy-on-update branch to trunk. I am still trying to
> > sort out what that means exactly.
>
> It means that svn 1.5 clients can now request that copyfrom-args be
> sent during updates, and 1.5 servers can oblige the request. What I'm
> now working on is making libsvn_wc actually *use* this new update
> information intelligently. At the moment, the update-editor just
> stupidly does an RA side-fetch of the copyfrom-path. Instead, the
> client code needs to try and locate the (possibly edited) file already
> in the wc. Stay tuned.
>
>
> > Dan reported an issue on IRC that it looks like he did not enter. He
> > could not commit a changelist because a file not in the changelist had
> > conflicts.
>
> Doh, that sounds like a stupid bug just begging for a test-case!
>
>
>
> >
> > One we might need to push to a new release if no one steps forward:
> >
> > 2238: svn propset/del/edit does not support URL argument
> >
>
> Argh, are we *still* debating this issue? We already added 'svn
> propedit URL' support. I suppose I can understand adding 'svn propdel
> URL' support (since we already support 'svn rm URL')... but I'm really
> against 'svn propset URL', and the issue claims there's still no
> consensus on that. I guess we should at least update the issue's
> summary.
I agree, I'd suggest we update the summary, close the issue and either
open a new one for propdel or wait for someone else to push for it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN 1.5 Status Update
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 9/9/07, Mark Phippard <ma...@gmail.com> wrote:
> Kamesh is still working on the new merge algorithm (2821) proposed by
> Peter Lundblad earlier this year.
Wow, Kamesh is a super-hero! :-)
> Ben merged his copy-on-update branch to trunk. I am still trying to
> sort out what that means exactly.
It means that svn 1.5 clients can now request that copyfrom-args be
sent during updates, and 1.5 servers can oblige the request. What I'm
now working on is making libsvn_wc actually *use* this new update
information intelligently. At the moment, the update-editor just
stupidly does an RA side-fetch of the copyfrom-path. Instead, the
client code needs to try and locate the (possibly edited) file already
in the wc. Stay tuned.
> Dan reported an issue on IRC that it looks like he did not enter. He
> could not commit a changelist because a file not in the changelist had
> conflicts.
Doh, that sounds like a stupid bug just begging for a test-case!
>
> One we might need to push to a new release if no one steps forward:
>
> 2238: svn propset/del/edit does not support URL argument
>
Argh, are we *still* debating this issue? We already added 'svn
propedit URL' support. I suppose I can understand adding 'svn propdel
URL' support (since we already support 'svn rm URL')... but I'm really
against 'svn propset URL', and the issue claims there's still no
consensus on that. I guess we should at least update the issue's
summary.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org