You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2008/08/18 09:34:45 UTC
Re: To Greg Stein
Stefan Sperling wrote:
> On Sun, Aug 17, 2008 at 03:39:49PM -0700, gstein@tigris.org wrote:
>
>> Author: gstein
>> Date: Sun Aug 17 15:39:48 2008
>> New Revision: 32515
>>
>> Log:
>> Another round of exploration on the API for the metadata/text-base
>> interface. There are three main sections now: manipulate the BASE tree,
>> perform mutation operations on the BASE/WORKING trees, and read state from
>> the BASE/WORKING trees.
>>
>
> I'm wondering: Shouldn't these commits go to a feature branch?
>
In general I dislike creating branches if the same work can be done on
trunk without affecting the rest of the code. And I don't see a problem
with including such work-in-progress code in a release.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 18, 2008 at 9:38 AM, Greg Stein <gs...@gmail.com> wrote:
>> Note that active development on libsvn_wc (version 1) is still
>> happening, e.g. on the tree-conflicts branch and on Rui Guo's
>> branch. So it would be nice to still have libsvn_wc in its
>> current state around, without wc-ng changes creeping in.
>> Especially on the tree-conflicts branch, which has also already
>> touched a lot of the current libsvn_wc code.
>
> My changes won't interfere with your work for at least a month, I'd
> think. I've gotta code and test a whole new storage subsystem, and
> that is completely orthogonal to other WC work.
>
> Are there any changes which can safely be backported from the branch?
> i.e. to minimize the delta between trunk/branch, and to get that work
> "visible" to the wc-ng work.
Julian was asking about getting the code in trunk a few weeks ago. I
do not think he got many responses. It was not necessarily ready to
go to trunk. His post was more like "this is what is done, this is
what needs to be done, at which point should we move it to trunk."
--
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: To Greg Stein
Posted by Martin Furter <mf...@rola.ch>.
On Mon, 18 Aug 2008, Greg Stein wrote:
> On Mon, Aug 18, 2008 at 7:35 AM, Hyrum K. Wright
> As I've been poring over svn_wc.h, I've been thinking that we need
> svn_deprecated.h and move all of the function signatures and types
> into that file. Let them all sit there, undocumented ("want doc? look
> in prior releases. kthxbai."). That header would then be included by
> all other headers (old code including (say) svn_wc.h still needs the
> deprecated API to be visible). Doing this would clean up our header
> files a LOT. Thoughts?
I like that idea, but I would add an #ifndef around it to be able to not
include deprecated functions. Something like this:
#ifndef SVN_NO_DEPERCATED_FUNCTINS
#include <svn_deprecated.h>
#endif
That way when porting to a new release of subversion it will be much
easier to find the replaced functions by setting that define.
Just my 2 cents.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 18 Aug 2008 at 12:41 -0700:
> On Mon, Aug 18, 2008 at 10:27 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Greg Stein wrote on Mon, 18 Aug 2008 at 08:05 -0700:
> >> As I've been poring over svn_wc.h, I've been thinking that we need
> >> svn_deprecated.h and move all of the function signatures and types
> >> into that file. Let them all sit there, undocumented ("want doc? look
> >
> > I like having the diff'ed doc-strings [1] available, using them is
> > easier than reading doc-strings on two branches and doing a mental diff.
> >
> > In other words, I think the doc-strings are useful :)
>
> Agreed. But I'm talking about the *deprecated* functions. Why do they
> need docstrings?
>
* So people looking to upgrade to the non-deprecated version know what
the differences are.
* Have everything in one place. If I wrote code against the 1.4 API, and
then upgraded *some* functions to their 1.5 API versions, and then
upgraded *some* other functions to their 1.6 API versions ...
I wouldn't want to have to look in three different include/ directories
whenever I try to understand the code I wrote. :)
> "We don't want you using these functions, so we're not going to document them."
>
"We don't want you using these functions, so we mark them as @deprecated.
We trust you to know not to use them in new code."
(And we tell you to define SVN_DEPRECATED_H if you want to find all calls
to deprecated functions.)
> Cheers,
> -g
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 18, 2008 at 10:27 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Greg Stein wrote on Mon, 18 Aug 2008 at 08:05 -0700:
>> As I've been poring over svn_wc.h, I've been thinking that we need
>> svn_deprecated.h and move all of the function signatures and types
>> into that file. Let them all sit there, undocumented ("want doc? look
>
> I like having the diff'ed doc-strings [1] available, using them is
> easier than reading doc-strings on two branches and doing a mental diff.
>
> In other words, I think the doc-strings are useful :)
Agreed. But I'm talking about the *deprecated* functions. Why do they
need docstrings?
"We don't want you using these functions, so we're not going to document them."
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 18 Aug 2008 at 08:05 -0700:
> As I've been poring over svn_wc.h, I've been thinking that we need
> svn_deprecated.h and move all of the function signatures and types
> into that file. Let them all sit there, undocumented ("want doc? look
I like having the diff'ed doc-strings [1] available, using them is
easier than reading doc-strings on two branches and doing a mental diff.
In other words, I think the doc-strings are useful :)
> in prior releases. kthxbai."). That header would then be included by
> all other headers (old code including (say) svn_wc.h still needs the
> deprecated API to be visible). Doing this would clean up our header
> files a LOT. Thoughts?
None.
Daniel
[1] "Similar to svn_foo1(), but with the @a parameter always set to @c", etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 18, 2008 at 7:35 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Greg Stein wrote:
>...
>> I'd much prefer to get rid of the wc1 code entirely.
>
> I think a number of us feel the same way, but while were at it, why don't we
> get rid of the clunky API[1]?
Quite possibly, yes. To be honest, I'm not sure how extensive these
changes could impact the API. I need to fully support the API
regardless, and doing that work will be very informative for what a
true wc-ng API could look like. Revamping _client to use an updated
API will further inform us.
But you can see where this is going: I don't know, don't need to know
now, and will deal with it later. :-)
I agree with the basic intent, and have made a note of it.
As I've been poring over svn_wc.h, I've been thinking that we need
svn_deprecated.h and move all of the function signatures and types
into that file. Let them all sit there, undocumented ("want doc? look
in prior releases. kthxbai."). That header would then be included by
all other headers (old code including (say) svn_wc.h still needs the
deprecated API to be visible). Doing this would clean up our header
files a LOT. Thoughts?
> We can continue to ship wc1 in parallel to
> wc-ng, but officially deprecate it and promise never to update or support
> it. If we really wanted to physically remove the wc1 code, we could
> reimplement wc1 as a thin wrapper around wc-ng. We wouldn't be breaking any
> compatibility guidelines *and* we'd get to remove API cruft.
I don't think it would proper for us to never update/support any code
we ship. Thus, wc1 would be a wrapper, which is my current intent. I
just don't know (yet) whether a wc-ng API would be radically different
from a wc1 API.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Greg Stein wrote:
> On Mon, Aug 18, 2008 at 6:21 AM, Stefan Sperling <st...@elego.de> wrote:
>> ...
>> Can we put new stuff into libsvn_wc2 then?
>
> I thought about this, but decided that would be seriously painful.
>
> Given our versioning guidelines, we have to support the WC API
> *forever* in the 1.x series of releases. That means we'd have to
> support wc1 forever. All that software out there using wc1 would have
> to continue to function.
>
> I'd much prefer to get rid of the wc1 code entirely.
I think a number of us feel the same way, but while were at it, why don't we get
rid of the clunky API[1]? We can continue to ship wc1 in parallel to wc-ng, but
officially deprecate it and promise never to update or support it. If we really
wanted to physically remove the wc1 code, we could reimplement wc1 as a thin
wrapper around wc-ng. We wouldn't be breaking any compatibility guidelines
*and* we'd get to remove API cruft.
Maybe I'm making a mountain out of a molehill here, but those are my thoughts.
-Hyrum
[1] svn_wc_add3() comes to mind. See this comment in libsvn_client/copy.c:
/* Rewrite URLs recursively, remove wcprops, and mark everything
as 'copied' -- assuming that the src and dst are from the
same repository. (It's kind of weird that svn_wc_add() is the
way to do this; see its doc for more about the controversy.) */
Re: To Greg Stein
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 18, 2008 at 6:21 AM, Stefan Sperling <st...@elego.de> wrote:
>...
> Can we put new stuff into libsvn_wc2 then?
I thought about this, but decided that would be seriously painful.
Given our versioning guidelines, we have to support the WC API
*forever* in the 1.x series of releases. That means we'd have to
support wc1 forever. All that software out there using wc1 would have
to continue to function.
I'd much prefer to get rid of the wc1 code entirely.
>...
> Note that active development on libsvn_wc (version 1) is still
> happening, e.g. on the tree-conflicts branch and on Rui Guo's
> branch. So it would be nice to still have libsvn_wc in its
> current state around, without wc-ng changes creeping in.
> Especially on the tree-conflicts branch, which has also already
> touched a lot of the current libsvn_wc code.
My changes won't interfere with your work for at least a month, I'd
think. I've gotta code and test a whole new storage subsystem, and
that is completely orthogonal to other WC work.
Are there any changes which can safely be backported from the branch?
i.e. to minimize the delta between trunk/branch, and to get that work
"visible" to the wc-ng work.
> There's no doubt that tree-conflicts and wc-ng need to merge
> at some point (or rather, even better tree-conflict handling
> needs to be added to wc-ng),
Yes and yes.
> but right now wc-ng is in too
> early a state of development to even think about doing this.
> We might still end up shipping tree-conflict handling
> based on libsvn_wc1 before wc-ng is stable.
Well, I think wc1 gets revamped rather than deprecated. In terms of
whether t-c is based on wc1 or wc-ng... I think we'll just have to see
how it goes.
And it looks like I'm going to need to do a diff between trunk/branch
and see what you've done so far.
>...
> Yes, that might be true. I've never reviewed a change this
> large, so I'll just have to take your word for it :)
hehe... yeah, it is true. Anything more than 1000 lines is effectively
unreviewable. wc-ng will be an order of magnitude larger than that.
>...
> Given that most of the work is done in new files, there's no problem
> with wc-ng work affecting other branches. But if that turns out not
> to be the case, I'd strongly favour branching.
Let's see where things are when I get the storage subsystem done. Your
work will definitely be much further along, and I'll hopefully have
more information about the "next steps" after the subsystem is in
place.
>...
> - Maintain both libraries for a while until the features
> of both libraries are on par, then deprecate and finally
> abandon libsvn_wc1.
This is the key part. We could deprecate wc1, but I think we'd always
have to fix bugs in it. And we could never truly abandon it
unless/until we shift to 2.0.
(and don't get me started on a 2.0 discussion :-P )
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Aug 18, 2008 at 08:41:36AM -0400, Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
> > In general I dislike creating branches if the same work can be done on
> > trunk without affecting the rest of the code. And I don't see a
> > problem with including such work-in-progress code in a release.
>
> I'm with Brane on this one. We haven't actually had a problem yet, and
> IMHO it's unlikely that we will. The new wc-ng code is quite separate
> from the old wc code. And there's nothing wrong with shipping a
> work-in-progress, as long as it's clearly labeled as such: we did that
> with serf for several releases, IIRC.
Can we put new stuff into libsvn_wc2 then?
Current commits seem to go directly to libsvn_wc.
Mixing both versions in a single directory on the same branch
is a bit chaotic. libsvn_wc2 could either start out as an empty
directory, or as a copy of libsvn_wc, whichever is more convenient.
Note that active development on libsvn_wc (version 1) is still
happening, e.g. on the tree-conflicts branch and on Rui Guo's
branch. So it would be nice to still have libsvn_wc in its
current state around, without wc-ng changes creeping in.
Especially on the tree-conflicts branch, which has also already
touched a lot of the current libsvn_wc code.
There's no doubt that tree-conflicts and wc-ng need to merge
at some point (or rather, even better tree-conflict handling
needs to be added to wc-ng), but right now wc-ng is in too
early a state of development to even think about doing this.
We might still end up shipping tree-conflict handling
based on libsvn_wc1 before wc-ng is stable.
> Regarding this:
>
> > a) It will make the end result of your effort much easier to review.
>
> With something like wc-ng, if we're not reviewing the commits as they
> come in, then it's hopeless anyway :-). Once finished, a change like
> that is much too big to review all at once.
Yes, that might be true. I've never reviewed a change this
large, so I'll just have to take your word for it :)
> (But just to play the other
> side: the bulk of the work is going into new files anyway, so if one
> wanted to review the "state of wc-ng" at any point, one would just look
> at those files.
This is inherently an argument in favour of a new directory, right?
Also, you seem to be addressing my point b) here, let me restate:
Potential problems caused by changes entering trunk affects *all*
feature branches, because they regularly sync with trunk
Given that most of the work is done in new files, there's no problem
with wc-ng work affecting other branches. But if that turns out not
to be the case, I'd strongly favour branching.
> This will remain true until the work starts touching
> libsvn_client, and at that point, I'd much rather have it in trunk so we
> can keep the changes closely coordinated with old libsvn_wc maintenance.)
OK. This implies that we'd want to support both working copy libraries
for a while. If that's the case, then it's obvious that we will
need both of them in trunk at some point anyway.
> Let's please go with trunk until there's actually a problem. We can
> make a branch at any time if we need to.
So if the plan for wc-ng is:
- Add new code in libsvn_wc2 only.
- Tweak some existing files to enable compile-time/run-time
switching between working copy library implementations.
Add other small glue that might be needed, but do NOT add new
features to existing code, and do NOT break existing code.
- Maintain both libraries for a while until the features
of both libraries are on par, then deprecate and finally
abandon libsvn_wc1.
... then I'm entirely OK with wc-ng development on trunk.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Karl Fogel <kf...@red-bean.com>.
"Greg Stein" <gs...@gmail.com> writes:
>> Basically, my thinking is: if I can avoid touching _client, then I've
>> done my work properly.
>
> Oh, and to respond to myself here :-P ... yes, eventually _client
> *will* get rebuilt. For example: all of the access batons will go
> away. But ideally that is a second pass of effort that occurs *after*
> WC has been rebuilt.
You read my mind :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Greg Stein <gs...@gmail.com>.
2008/8/18 Greg Stein <gs...@gmail.com>:
>...
> Basically, my thinking is: if I can avoid touching _client, then I've
> done my work properly.
Oh, and to respond to myself here :-P ... yes, eventually _client
*will* get rebuilt. For example: all of the access batons will go
away. But ideally that is a second pass of effort that occurs *after*
WC has been rebuilt.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Aug 18, 2008 at 5:41 AM, Karl Fogel <kf...@red-bean.com> wrote:
> Branko Čibej <br...@xbc.nu> writes:
>> In general I dislike creating branches if the same work can be done on
>> trunk without affecting the rest of the code. And I don't see a
>> problem with including such work-in-progress code in a release.
>...
> side: the bulk of the work is going into new files anyway, so if one
> wanted to review the "state of wc-ng" at any point, one would just look
> at those files. This will remain true until the work starts touching
> libsvn_client, and at that point, I'd much rather have it in trunk so we
> can keep the changes closely coordinated with old libsvn_wc maintenance.)
I think we may have different assumptions here:
* sounds like you're thinking of a new WC library which _client starts to use
* I'm thinking rewrite WC under the covers
Basically, my thinking is: if I can avoid touching _client, then I've
done my work properly.
So your basic statement about "when it touches" is valid, but it is
_wc rather than _client. And per my other note, that is the
no-going-back point when we need to make a decision w.r.t the 1.6
release.
Cheers,
-g
Re: To Greg Stein
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> In general I dislike creating branches if the same work can be done on
> trunk without affecting the rest of the code. And I don't see a
> problem with including such work-in-progress code in a release.
I'm with Brane on this one. We haven't actually had a problem yet, and
IMHO it's unlikely that we will. The new wc-ng code is quite separate
from the old wc code. And there's nothing wrong with shipping a
work-in-progress, as long as it's clearly labeled as such: we did that
with serf for several releases, IIRC.
Regarding this:
> a) It will make the end result of your effort much easier to review.
With something like wc-ng, if we're not reviewing the commits as they
come in, then it's hopeless anyway :-). Once finished, a change like
that is much too big to review all at once. (But just to play the other
side: the bulk of the work is going into new files anyway, so if one
wanted to review the "state of wc-ng" at any point, one would just look
at those files. This will remain true until the work starts touching
libsvn_client, and at that point, I'd much rather have it in trunk so we
can keep the changes closely coordinated with old libsvn_wc maintenance.)
Let's please go with trunk until there's actually a problem. We can
make a branch at any time if we need to.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org