Strange subject line :-P
On Mon, Aug 18, 2008 at 1:11 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sun, Aug 17, 2008 at 03:39:49PM -0700, gstein_at_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.s_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-18 15:00:35 CEST