You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@elego.de> on 2008/08/18 08:11:05 UTC
To Greg Stein (was: Re: svn commit: r32515 -
trunk/subversion/libsvn_wc)
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?
Because:
a) It will make the end result of your effort much easier to review.
People can just diff the feature branch against trunk and see
the end result of all your changes in one batch.
b) Potential problems caused by changes entering trunk affects *all*
feature branches, because they regularly sync with trunk.
In the long run, committing many small work-in-progress
changes to trunk could mean that conflict resolution might need
to be done several times on several of our branches (as soon
as you start changing existing files, that is).
This gets even worse in case files are deleted/moved around etc,
which is something you may want to do while reworking libsvn_wc.
Because then we can run into tree conflicts which are sometimes
non-obvious, and merging trunk to feature branches to keep them
in sync gets even harder (unless we like merge errors).
For this reason it's better to merge the known-working end
result into trunk and let other feature branches do catch-up
work with your feature just once.
c) A branch can optionally give the work you are currently doing a scope.
That is, you could name the branch "branches/wc-ng" (scope: everything
under the sun people might want to have in wc-ng) or e.g.
"branches/centralised-wc-meta-data" (scope: implement centralised
meta-data storage for libsvn_wc).
I guess taking multiple smallish steps towards the ultimate goal
of a "new working copy" might help people who would like to get
involved at different stages (e.g. me, and I bet a bunch of others
are also interested).
For example, as I already pointed out we *need* to make the new
working copy smarter about tree conflicts. If we don't do that
eventually, we totally lose, and can scrap this whole project, and
spend our time on a different version control system, IMHO.
This is really important to me.
However, doing this is a separate problem from changing meta data
location. So these can be done in two separate steps, on two separate
branches, perhaps. There may be more bite-sized tasks like these
which ultimately lead up to the next-generation working copy.
Since you're currently putting more brain power into this than anyone
else here, could you identify and describe some of the subtasks you're
currently seeing which might warrant their own feature branches, if any?
Just some thoughts.
Thanks,
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:
> The big question is whether this goes into 1.6 or not. On the roadmap,
> I see there is a hope to release 1.6 at the end of the year. I'm
> hoping to be done in time for that. But that's pretty aggressive. So
> the next question becomes: hold 1.6, or just include some dead code in
> 1.6? At some point, there will be a "no turning back" commit that puts
> the WC onto its new track. We'll have to discuss/judge at that point.
> *That* commit may start a branch so that it can route around a 1.6
> release.
After the 1.5 delay, we pretty much decided not to hold releases for
particular features. Let's stick to that. Maybe if it were a smallish
feature, and really close to being done, and we could all see the scope
clearly, we'd delay a release by a week or something... But a wc
rewrite? If it doesn't make the 1.6 train, then the 1.7 will be along
any day now :-).
> I'm actually thinking that making all active developers deal
> with it (tho I'll try to minimize, of course) may be the right
> approach.
+1
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein (was: Re: svn commit: r32515 -
trunk/subversion/libsvn_wc)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Mon, 18 Aug 2008 at 06:00 -0700:
> On Mon, Aug 18, 2008 at 1:30 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >...
> > d) It will allow us to work on wc-ng without automatically including it
> > (in whatever shape it is then) in the next release.
>
> I'm with Branko: not to worried about this.
>
> The big question is whether this goes into 1.6 or not. On the roadmap,
> I see there is a hope to release 1.6 at the end of the year. I'm
> hoping to be done in time for that. But that's pretty aggressive. So
> the next question becomes: hold 1.6, or just include some dead code in
> 1.6? At some point, there will be a "no turning back" commit that puts
> the WC onto its new track. We'll have to discuss/judge at that point.
> *That* commit may start a branch so that it can route around a 1.6
> release.
>
Fair enough -- let's cross the bridge when we get to it. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: To Greg Stein (was: Re: svn commit: r32515 - trunk/subversion/libsvn_wc)
Posted by Greg Stein <gs...@gmail.com>.
Strange subject line :-P
On Mon, Aug 18, 2008 at 1:11 AM, Stefan Sperling <st...@elego.de> 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?
Not necessarily, which is why I haven't done that so far.
> Because:
>
> a) It will make the end result of your effort much easier to review.
$ wc -l libsvn_wc/*.c
...
28717 total
A rewrite of WC is *never* going to be reviewable at the end. The only
possible way to get it reviewed is during development. And I know that
some people will skip branch reviews, meaning we could end up with
less review. And given the fragile nature of WC, its central nature to
svn, and the importance of this work (how many years have we asked for
a rewrite?), then I concluded that doing as much as possible of the
work on trunk is proper.
>...
> b) Potential problems caused by changes entering trunk affects *all*
> feature branches, because they regularly sync with trunk.
Great. More testing. :-)
In all seriousness, I fear isolating the work on a branch. This work
*will* go into a release, and it has got to be tested out the wazoo.
It is a rewrite. Not just a feature change. And historically in
software, a rewrite is a fertile home for bugs. Thus, lots of unit
tests and reviews and testing is very important.
> In the long run, committing many small work-in-progress
> changes to trunk could mean that conflict resolution might need
> to be done several times on several of our branches (as soon
> as you start changing existing files, that is).
It's gotta happen sometime. And merging a 20k line change from a
branch to trunk, performing conflict resolution at that point is a
recipe for disaster. Not the least of which is a conflict which is
semantic rather than textual -- it won't get flagged.
> This gets even worse in case files are deleted/moved around etc,
> which is something you may want to do while reworking libsvn_wc.
> Because then we can run into tree conflicts which are sometimes
> non-obvious, and merging trunk to feature branches to keep them
> in sync gets even harder (unless we like merge errors).
Well, then I'll just avoid that. Or if it "needs" to happen, then it
can just be marked into a TODO and done after those branches are
merged, or maybe coordinate closely with the branch developers. And
how many branches are we really speaking of here? Two maybe?
> For this reason it's better to merge the known-working end
> result into trunk and let other feature branches do catch-up
> work with your feature just once.
There may be portions of this work that will need to happen on a
branch. I can't say for sure yet, since this is some hairy freakin'
shit, and I'm not entirely sure of the whole roadmap yet. However, my
goal is to do the development incrementally enough that we are
comfortable it is "known-working" all the time.
> c) A branch can optionally give the work you are currently doing a scope.
Don't need it. That's what mailing list discussions are for.
>...
> I guess taking multiple smallish steps towards the ultimate goal
> of a "new working copy" might help people who would like to get
> involved at different stages (e.g. me, and I bet a bunch of others
> are also interested).
Sure. But I'm hoping/planning to just do that steps in trunk. I've
been trying to put as much of my thoughts into wc-ng-design as
possible for others to follow, and will continue to do that. (there
are probably some half-thoughts that I could still add to that file,
now that I think about it)
> For example, as I already pointed out we *need* to make the new
> working copy smarter about tree conflicts. If we don't do that
> eventually, we totally lose, and can scrap this whole project, and
> spend our time on a different version control system, IMHO.
Heh. I've heard that one before. :-P
> This is really important to me.
Yup! And so I hope that you'll be able to advise/help on the design
and/or coding. I'd definitely like to understand a bit more of the
tree conflict issue to ensure that enough data to support it is
recorded in the new storage subsystem.
>...
> Since you're currently putting more brain power into this than anyone
> else here, could you identify and describe some of the subtasks you're
> currently seeing which might warrant their own feature branches, if any?
Well, no... not really :-P Once I have the new storage subsystem,
then everything gets rewritten on top of that. All the editors, the
various query systems, the mutation mechanisms, etc. In what order?
Dunno. Are they divisible tasks? Hope so. What are they? Beats me.
In short, I dunno either. But I don't need the answer today, so I'm
not worrying about it yet. Maybe when I *do* need it, it will have
percolated long enough in the back of my head that I'll have an
answer.
On Mon, Aug 18, 2008 at 1:30 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>...
> d) It will allow us to work on wc-ng without automatically including it
> (in whatever shape it is then) in the next release.
I'm with Branko: not to worried about this.
The big question is whether this goes into 1.6 or not. On the roadmap,
I see there is a hope to release 1.6 at the end of the year. I'm
hoping to be done in time for that. But that's pretty aggressive. So
the next question becomes: hold 1.6, or just include some dead code in
1.6? At some point, there will be a "no turning back" commit that puts
the WC onto its new track. We'll have to discuss/judge at that point.
*That* commit may start a branch so that it can route around a 1.6
release.
> e) It gives us a name (the branch's name) we can refer to when people
> ask "Why haven't you written $feature yet?" :)
"We are. It's happening in trunk."
I'll close with one more comment, and this is also one of the largest
reasons that I am trying to do this work on trunk. The merge work was
initially done on a branch. A *lot* of work was done, and it became
hell to merge (haha) onto trunk. That merge also happened *way* too
late (IMO). Personally, I think the branch approach for the merge
work, and the delays in merging it, was a terrible, *terrible*
disservice to svn. The time gap between 1.4 and 1.5 was (again, imo)
awful. I was on the sidelines, so there were only so many rocks I
could throw, but I *really* don't want to see something like that
happen again. I fear another two year release cycle. This isn't just
some feature, but a deep and complete rewrite of a core/critical piece
of svn. I'm actually thinking that making all active developers deal
with it (tho I'll try to minimize, of course) may be the right
approach.
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 (was: Re: svn commit: r32515 -
trunk/subversion/libsvn_wc)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, 18 Aug 2008 at 10:11 +0200:
> 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?
>
+1
> Because:
>
> a) It will make the end result of your effort much easier to review.
>
> b) Potential problems caused by changes entering trunk affects *all*
> feature branches, because they regularly sync with trunk.
>
> c) A branch can optionally give the work you are currently doing a scope.
>
d) It will allow us to work on wc-ng without automatically including it
(in whatever shape it is then) in the next release.
e) It gives us a name (the branch's name) we can refer to when people
ask "Why haven't you written $feature yet?" :)
Daniel
>
> Just some thoughts.
>
> Thanks,
> 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 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
Re: To Greg Stein
Posted by Branko Čibej <br...@xbc.nu>.
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