You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/07/11 18:52:21 UTC
Alpha issues [or "How to Organize Your Weekend" :-) ]
Issue #749 -- revamping WC operations to enforce lock/log policies via
an access_baton, also caching entries lists -- is not officially
marked as Alpha, but would be nice to get done for Alpha (Monday!).
Philip Martin, Justin, Kevin, et al have already started on it. The
speedups Justin got by experimenting with entry caching are incredible
(and just *imagine* how much faster "make check" will run when this is
done everywhere!). I don't know if it would be feasible to try and
get this issue done in a weekend, but if it is, it would be great to
have in Alpha. That said, it's all up to you guys -- as you'll see
below, we're fairly occupied with the official Alpha issues here in
the Chicago office :-). So go for it, if you think it can be done in
time without compromising quality. But if it's too big, don't worry
about it.
As for the remaining Alpha list, here's a quick status report. See
especially the first item...
751: need an svn-config file
==> Ben and I are planning to take a look at this tomorrow. BUT,
if someone wants to do this, go for it! Just take a look at
apu-config for example, and post with questions. We'd love
to be able to concentrate on issue #494 and friends :-).
724: construct libsvn_auth
==> Greg Stein's back and planning to do this one.
690: Alpha"svn log" should print changed paths
745: Filesystem optimizations
754: Fix fs automerge to preserve history correctly
==> Mike Pilato is almost done with these.
531: undeltification improvements
==> Brane is working on this one. I think it's probably going to
need more testing before it goes into the trunk, so it may
not actually make it into alpha. However, this doesn't
necessarily mean we'll need another repository dump/load
cycle in the future, as I believe Brane needs no further
table changes in trunk for this. (Brane?)
494: need path escaping (URI, XML, etc.), and UTF-8 conversion
667: case sensitivity needs to be done portably
==> Ben and I are finishing these.
773: PROPFIND on large dir takes excessive memory/time
==> Greg Stein will fix this if he has time. It's a mod_dav
(not even mod_dav_svn) issue, and it could conceivably get
pushed to Beta, as it's more a performance than correctness
issue.
That's all for now,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 11, 2002 at 04:13:25PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > It kind of fell into the "minor feature" bucket, and seemed to be okay to
> > delay until Beta. If you'd like to start work on it... feel free, of course!
>
> +1
>
> Though let's not fool ourselves: we will be adding new config options
> between Alpha and 1.0 anyway, because we're going to think of ones we
> "can't live without". So there's no urgency that this be an Alpha
> issue. But to have some of this stuff in there for Alpha would be a
> fine thing...
Yup. Kind of a "got the structural stuff set up. feel free to add options."
kind of thing.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> It kind of fell into the "minor feature" bucket, and seemed to be okay to
> delay until Beta. If you'd like to start work on it... feel free, of course!
+1
Though let's not fool ourselves: we will be adding new config options
between Alpha and 1.0 anyway, because we're going to think of ones we
"can't live without". So there's no urgency that this be an Alpha
issue. But to have some of this stuff in there for Alpha would be a
fine thing...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 11, 2002 at 03:50:10PM -0400, Kevin Pilch-Bisson wrote:
> Hey just noticed that issue #668 (~/.subversion/config file for diff option,
> editor, security, etc) is not marked as an alpha issue. It would make sense
> to me that a client config file (including all of the config options we have
> said we want to support should be an alpha issue. It's currently marked as a
> Beta issue, but it's a feature not a bugfix. Is this right?
It kind of fell into the "minor feature" bucket, and seemed to be okay to
delay until Beta. If you'd like to start work on it... feel free, of course!
As with any work we're doing, if the feature gets mostly done by Monday, and
is just a day away from being completed, then it is certainly in all our
interests to wait a day for Alpha to be released.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
Hey just noticed that issue #668 (~/.subversion/config file for diff option,
editor, security, etc) is not marked as an alpha issue. It would make sense
to me that a client config file (including all of the config options we have
said we want to support should be an alpha issue. It's currently marked as a
Beta issue, but it's a feature not a bugfix. Is this right?
On Thu, Jul 11, 2002 at 01:52:21PM -0500, Karl Fogel wrote:
> Issue #749 -- revamping WC operations to enforce lock/log policies via
> an access_baton, also caching entries lists -- is not officially
> marked as Alpha, but would be nice to get done for Alpha (Monday!).
>
> Philip Martin, Justin, Kevin, et al have already started on it. The
> speedups Justin got by experimenting with entry caching are incredible
> (and just *imagine* how much faster "make check" will run when this is
> done everywhere!). I don't know if it would be feasible to try and
> get this issue done in a weekend, but if it is, it would be great to
> have in Alpha. That said, it's all up to you guys -- as you'll see
> below, we're fairly occupied with the official Alpha issues here in
> the Chicago office :-). So go for it, if you think it can be done in
> time without compromising quality. But if it's too big, don't worry
> about it.
>
> As for the remaining Alpha list, here's a quick status report. See
> especially the first item...
>
> 751: need an svn-config file
> ==> Ben and I are planning to take a look at this tomorrow. BUT,
> if someone wants to do this, go for it! Just take a look at
> apu-config for example, and post with questions. We'd love
> to be able to concentrate on issue #494 and friends :-).
>
> 724: construct libsvn_auth
> ==> Greg Stein's back and planning to do this one.
>
> 690: Alpha"svn log" should print changed paths
> 745: Filesystem optimizations
> 754: Fix fs automerge to preserve history correctly
> ==> Mike Pilato is almost done with these.
>
> 531: undeltification improvements
> ==> Brane is working on this one. I think it's probably going to
> need more testing before it goes into the trunk, so it may
> not actually make it into alpha. However, this doesn't
> necessarily mean we'll need another repository dump/load
> cycle in the future, as I believe Brane needs no further
> table changes in trunk for this. (Brane?)
>
> 494: need path escaping (URI, XML, etc.), and UTF-8 conversion
> 667: case sensitivity needs to be done portably
> ==> Ben and I are finishing these.
>
> 773: PROPFIND on large dir takes excessive memory/time
> ==> Greg Stein will fix this if he has time. It's a mod_dav
> (not even mod_dav_svn) issue, and it could conceivably get
> pushed to Beta, as it's more a performance than correctness
> issue.
>
> That's all for now,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
> > 751: need an svn-config file
> > ==> Ben and I are planning to take a look at this tomorrow. BUT,
> > if someone wants to do this, go for it! Just take a look at
> > apu-config for example, and post with questions. We'd love
> > to be able to concentrate on issue #494 and friends :-).
>
> I can do this.
Awesome, thanks! I saw the other followups on this thread, and assume
you did too. As soon as Issuezilla is showing bugs again (it's
experiencing bad weather at the moment) I'll assign this one over to
you.
Also, folks, there's one other issue that could be fixed in Alpha, if
someone wants to take it on:
http://subversion.tigris.org/issues/show_bug.cgi?id=611
Note that there are two parts to this issue. The first part is kind
of complex -- it's about how when you "svn mv A A2" (where A is a
versioned directory), a skeletal A tree is left around afterwards.
This is a side effect of the fact that "mv" is really "svn cp A A2;
svn rm A". The problem is that "svn rm" wants to leave around A's
tree, with all the .svn subdirs and text bases, so that "svn revert"
will work later. Of course, it doesn't know that it could get all
that stuff from A2 if it had to.
Solving this first part of the bug is too complex for Alpha. In fact
it's debatable that it needs to be solved at all, since you could have
done
$ svn mv ./A ../../A2
$ svn revert --recursive .
and it can get really hard to revert this stuff unless the base tree
is still around.
However, the *second* part of the issue is very simple: it's that even
after you commit the removal, the old tree stays around in skeleton
form. Solving this is pretty non-controversial -- the old tree should
simply get removed, except for paths down to local mods. Philip
Martin has some more comments in the issue, see there for details.
Why is this a potential Alpha fix?
Ben Collins-Sussman pointed out that directory versioning is our big
selling point, so everyone who sees we're at Alpha and downloads SVN
for the first time will want to play around with "svn cp" and "svn
mv", on both files and directories. It would be a pity (though not an
insurmountable pity) if things behaved wierdly for them -- for
example, the SRC tree of "svn mv SRC DST" remaining in their working
copy even *after* they commit :-).
So it would be nice if someone wanted to try swatting the post-commit
bug here.
If not, no big deal, we'll just list the misbehavior on our
Inconveniences Page and do it for Beta.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Jul 11, 2002 at 12:17:26PM -0700, Justin Erenkrantz wrote:
> I can do this. Do you want svn-config to tell you anything more than
> what {apr|apu}-config says? IIRC, Greg was mentioning also to
> integrate with pkg-config. My take is that pkg-config isn't going to
> be installed at enough places to warrant anyone using that.
while i have no problem with providing a .pc file for pkg-config, i'd
prefer that we have our own svn-config script so that we aren't
depending on it being there for this functionality, so +1 on a separate
script.
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 11, 2002 at 12:17:26PM -0700, Justin Erenkrantz wrote:
> On Thu, Jul 11, 2002 at 01:52:21PM -0500, Karl Fogel wrote:
> > Issue #749 -- revamping WC operations to enforce lock/log policies via
> > an access_baton, also caching entries lists -- is not officially
> > marked as Alpha, but would be nice to get done for Alpha (Monday!).
>
> If the baton starts getting passed around soon-ish (say by this
> weekend), I can try to have the caching in. I know what has to be
> done, I just don't know how the API will shake out.
Also, consider whether there is a partial solution that gives you the 80%
bang. (although I've never been in favor of hacks to meet a deadline; I'm
just commenting on the possibility that you might have a dev plan that meets
your needs and is "nice" at the time we snapshot)
> > 751: need an svn-config file
> > ==> Ben and I are planning to take a look at this tomorrow. BUT,
> > if someone wants to do this, go for it! Just take a look at
> > apu-config for example, and post with questions. We'd love
> > to be able to concentrate on issue #494 and friends :-).
>
> I can do this. Do you want svn-config to tell you anything more than
> what {apr|apu}-config says?
Nope. And even simpler since there is no Expat to worry about.
> IIRC, Greg was mentioning also to
> integrate with pkg-config. My take is that pkg-config isn't going to
> be installed at enough places to warrant anyone using that.
Separate issue. And Jon Trowbridge said that he would work on this one. As a
precursor to a subversion .pc file, he said that he wants .pc files for APR
and APRUTIL. Thus, it will be a bit longer before we see .pc files.
And I'm with Garrett on this: svn-config will be handy without needing the
pkgconfig framework.
> > 773: PROPFIND on large dir takes excessive memory/time
> > ==> Greg Stein will fix this if he has time. It's a mod_dav
> > (not even mod_dav_svn) issue, and it could conceivably get
> > pushed to Beta, as it's more a performance than correctness
> > issue.
>
> I think this is about as resolved as it will be until resource->pool
> gets fragmented in mod_dav.
The memory issue, yes. However, we can solve the latency problem by flushing
each "response" down the output stack as they are generated. Currently,
mod_dav buffers the entire response.
>...
> Hopefully, with my recent patches to mod_dav_svn, we should be a bit
> better off than before - perhaps enough so that we can delay this
> to beta. -- justin
Yes, we definitely could, and the Chicago guys even suggested moving this
issue to beta. I asked that it remains in alpha as a marker for the Apache
work that I'd like to do (unless you beat me to it :-) to reduce the
latency. Once I fix the latency, then we'll shift the issue to beta for
further resolution.
(note that changes *will* occur within mod_dav_svn -- the mod_dav backend
API needs to pass temp pools)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Jul 11, 2002 at 01:52:21PM -0500, Karl Fogel wrote:
> Issue #749 -- revamping WC operations to enforce lock/log policies via
> an access_baton, also caching entries lists -- is not officially
> marked as Alpha, but would be nice to get done for Alpha (Monday!).
If the baton starts getting passed around soon-ish (say by this
weekend), I can try to have the caching in. I know what has to be
done, I just don't know how the API will shake out.
> 751: need an svn-config file
> ==> Ben and I are planning to take a look at this tomorrow. BUT,
> if someone wants to do this, go for it! Just take a look at
> apu-config for example, and post with questions. We'd love
> to be able to concentrate on issue #494 and friends :-).
I can do this. Do you want svn-config to tell you anything more than
what {apr|apu}-config says? IIRC, Greg was mentioning also to
integrate with pkg-config. My take is that pkg-config isn't going to
be installed at enough places to warrant anyone using that.
> 773: PROPFIND on large dir takes excessive memory/time
> ==> Greg Stein will fix this if he has time. It's a mod_dav
> (not even mod_dav_svn) issue, and it could conceivably get
> pushed to Beta, as it's more a performance than correctness
> issue.
I think this is about as resolved as it will be until resource->pool
gets fragmented in mod_dav. The problem is that mod_dav needs a pool
that will only store what is on the output. There are temporary
mod_dav internal allocations that are done in resource->pool. So,
mod_dav needs to be a bit better about subpools. I'm seeing
resource->pool is accounting for about 60MB out of my remaining
110MB. So, I would focus on splitting that up using iterative
subpool strategies.
Hopefully, with my recent patches to mod_dav_svn, we should be a bit
better off than before - perhaps enough so that we can delay this
to beta. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> The required change (no overlapping windows when creating a delta) is
> already on the trunk, and well tested. That's all that needs to be
> done before the DB reload.
Cool.
> The combiner is up and running on branches/issue-531-dev, but indeed
> needs more testing. (Only one of our tests is failing, which is a good
> sign). Unfortunately I'll be away until late Sunday, so It'll not be
> in shape for trunk by Monday.
That's fine. There's no need to have this in Alpha -- far more
important that it be thoroughly tested over a long period of time.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Alpha issues [or "How to Organize Your Weekend" :-) ]
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> 531: undeltification improvements
> ==> Brane is working on this one. I think it's probably going to
> need more testing before it goes into the trunk, so it may
> not actually make it into alpha. However, this doesn't
> necessarily mean we'll need another repository dump/load
> cycle in the future, as I believe Brane needs no further
> table changes in trunk for this. (Brane?)
>
>
The required change (no overlapping windows when creating a delta) is
already on the trunk, and well tested. That's all that needs to be done
before the DB reload.
The combiner is up and running on branches/issue-531-dev, but indeed
needs more testing. (Only one of our tests is failing, which is a good
sign). Unfortunately I'll be away until late Sunday, so It'll not be in
shape for trunk by Monday.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org