You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Neels J. Hofmeyr" <ne...@elego.de> on 2008/11/16 01:16:56 UTC
Lose users? -- was: Re: Update on my previous tree conflict scenario
Stefan Sperling wrote:
> On Sat, Nov 15, 2008 at 10:21:49AM +0200, Daniel Shahaf wrote:
>> Neels J. Hofmeyr wrote on Sat, 15 Nov 2008 at 04:10 +0100:
>>> And the same for merge. Further guidance from `svn info':
>>>
>>> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
>>> <Info stuff>
>>> <Tree conflict stuff> You have edited file foo but an update tried to
>>> delete, possibly as part of a move.
>>> <In case of D -> M, also show this:>
>>> Hint: This kind of conflict may require `svn revert' to be resolved. Do
>>> make sure that your local modifications are copied somewhere safe first.
>>>
>> I wouldn't mind having this info somewhere (svn resolve --show-suggestions
>> victim_path), but I suspect any kind of "hint" shown by default will
>> eventually get annoying (once I know what it's going to say). Hard to say
>> without having seen it in practice (during my work), though.
>
> The problem is: We ourselves don't even know how to resolve each
> individual conflict in the entire set of possible tree conflicts.
> We've never tried to resolve them all.
>
> I am all +1 on adding some form of guidance to the UI,
> see the "tree conflicts from user's point of view" thread:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=145339
>
> But I think it's a bad idea to start putting hints in the UI without
> having a proper plan mapped out on how we can treat each individual
> conflict scenario, or without knowing whether there is some general way
> that will be able to deal with any possible scenario.
>
> The inconsistencies and weirdness people are seeing in the UI
> are real problems. We have to fix those. So far, most of the tree
> conflicts work was about detection and preventing commits. That
> seems to work fine now.
>
> The 'svn status' interface is still under discussion, and certainly
> a very important part of the UI:
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=14432
>
> Another UI discussion is here:
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142893
> but note how 'svn resolve' is being hinted at but left unspecified at the
> end of that mail (we only ever talked about 'svn resolveD' AFAIK).
>
> I have started walking through some cases in the "tree conflicts from
> user's point of view" thread linked above, just to see what the experience
> is like with the current state of things. I would like to encourage people
> to pick a scenario and walk through it, evaluating how to resolve the
> conflict, for each possible desired merge result if time permits, and
> state what they liked about the experience and what they didn't like.
> Feedback by developers or advanced users who have never concerned
> themselves with tree conflicts before would be most valuable.
>
> I have a couple of scripts that produce tree conflict scenarios to
> work with, so you don't have to make up your own scenarios:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=15317
> You can use these scripts easily if you have a current trunk
> build in your shell's PATH. Sorry, I don't have windows versions
> of these scripts, so you need cygwin or a unix-like OS to run them.
>
> I know it's tedious to walk through these cases, but if we don't
> critically examine and improve our current tree conflicts UI before
> release and end up shipping the release with a bad UI, my intuition
> is that people will complain as badly as they are complaining about
> the current merge-tracking problems in 1.5.x.
>
> We can use a lot of users over this if we don't get this right.
You mean "lose".
Yes, I agree. I'm seeing some parallels to the bad experiences described in
Hyrum's paper that was recently posted to the committers list. It feels like
we are again defining 1.6 as "the release that can handle tree-conflicts",
while we are at a point in time where tree-conflicts should ideally be
stable (as of last Wednesday), but instead we're stumbling across newly
discovered bugs (and even a design flaw once) on a pretty much regular basis.
We might well be able to stabilize tree-conflicts stuff in a matter of
weeks. Then again, we might not! That would mean we are repeating 1.5, while
everyone was saying "we *must not* repeat 1.5".
Needless to say that a bunch of people (probably including my employers)
would be awfully pissed off if tree-conflicts didn't make it into 1.6. But
what about the big rest of Subversion use, at large?
Should we maybe think of a Plan B? What parts of tree-conflicts handling
could just be disabled so that 1.6 becomes stable without removing
tree-conflicts altogether?
What are your views, everyone...
~Neels
Re: T/C and 1.6 (was Re: Lose users?)
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Nov 17, 2008 at 7:05 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Justin Erenkrantz wrote:
>> On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>> Producing some kind of definition of the remaining tree conflicts work for 1.6
>>> will help the community understand what's left to do, and more importantly help
>>> the tree-conflicts folks understand what's left. It may even get a few more
>>> people involved if there are well-scoped bite-sized tasks available.
>>>
>>> Neels, Stefan, Julian, et al: I await your list of what's left. :)
>>
>> My suggestion from the peanut gallery is:
>>
>> 1) We should await a review of what is 'left' on tree conflicts
>> 2) Ensure ourselves as a community that it is doable within <1 mo of work
>> 3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
>> 4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
>> releases, but just ensuring dev@ is happy with it)
>> 5) Merge approved backports and whatever is on the list of to-do for
>> tree conflicts
>> 6) Once tree conflicts is API-stable, begin formal stabilization procedures
>>
>> My point is really that we begin the stabilization of the rest of the
>> code as soon as possible, get trunk back to be open (waves bye-bye to
>> ra_neon *grin*), and merge tree conflicts stuff and start the final
>> stabilization as soon as it's API-stable.
>>
>> If the tree conflicts stuff can't be resolved within 1 mo or it takes
>> longer than that, then we yank the APIs for 1.6.x and it continues
>> apace for 1.7.x and we release 1.6.x without it. (I'm okay with
>> shipping dead code if it makes the RM process simpler as long as it
>> doesn't expose any APIs.)
>
> After talking with Karl in IRC just now, my view is kind of changing:
>
> Let's yank the APIs now, branch 1.6.x at the end of the week, stabilize, and
> release 1.6 with the currently implemented features.
>
> We want to delay 1.6 so that people can get tree conflicts sooner, implying that
> a soonish 1.6 is better than waiting a few months beyond that for 1.7. But we
> forget that we've got a lot of stuff already in 1.6, some work needed to
> stabilize that work, and good motivation to get that out to users right now.
>
> I think the trepidation to yank the tree conflicts APIs for 1.6 comes from the
> innate emotional attachment developers tend to have to their own code and a
> desire to see it ship. I also think that there may be a voice in many people's
> minds that says "we need to get tree conflicts in 1.6, because we still don't
> know if our time-based releases will work out and 1.7 will be soon after 1.6."
> As hokey as it sounds, we need to exercise some faith in our process, release
> 1.6, and know that 1.7 will be coming soon.
>
> As a thought experiment, how difficult would it be to release 1.6 without tree
> conflicts?
This sounds premature ... in the sense that you want to make a drastic
decision without giving us a chance to know all the options. The
remaining work might be manageable, or it might be possible to just
rip out a part of it where most of the remaining issues lie and still
deliver some of the value now in 1.6. The similarity that I see with
1.5 is that we have a group of developers that are taking a lot of
time to explain the current state and ask the rest of us for opinions
on things like UI etc. and not getting a lot of feedback from anyone
outside their circle. We want them to just tell us everything is good
without looking at what they have done.
In some of the limited tests I have run with the feature it seems to
work pretty well at its core function of identifying tree conflicts.
It gets confusing knowing what to do next, but I have a feeling we
could wait until 1.8 and this confusion is not going to go to away.
Conflicts are difficult. If they weren't, then the tool would just
resolve them. I do not think we'll ever have some single magic UI you
use to resolve a tree conflict. What I have focused on is whether it
keeps the WC in a valid state and whether we provide the user the
tools (subcommands) to work with it. It seems to be getting better.
If we completely wait for 1.7 then we are going to be faced with some
of the problems we had in 1.5 in that we will have at least two and
possible three big features all landing at once. This could be good
... if the tree conflicts API is not locked down and the WC is being
rewritten than we do not have to live with any bad decisions. This
could be bad ... in that we underestimate how much the intersection of
these two features slow each other down and get in each others way.
This happened with sparse directories and merge tracking and could
happen here.
Anyway, I am not against the idea but would still like to hear more
about what our options are. It does not seem like a productive usage
of our time to spend a few weeks ripping out work that has been going
for most of the year. And then have to turn around and put it back --
if we have other options. I agree we ought not wait another four to
six weeks to branch.
Finally, I am starting to think I agree with Greg that we ought to
stabilize on trunk and then branch and do an RC. After seeing your
paper on the 1.5 release it seems like the releases where things went
the smoothest that is exactly what happened, and the ones where we
branched and then stabilized are the ones that took forever to finish.
If you consider this recent tree conflicts work part of the
stabilization then we are not really doing that bad.
--
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: T/C and 1.6 (was Re: Lose users?)
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-11-18 at 14:06 +0100, Stefan Sperling wrote:
> On Tue, Nov 18, 2008 at 04:46:30AM +0100, Neels J. Hofmeyr wrote:
> > Julian suggested that it would be feasible to disable tree-conflicts
> > detection upon update and leave it in for merge (I'd think it's possible
> > within very short notice, a couple hours for this one). TC on update are
> > inherently more complex than merge, because they need to take care about
> > updating the base or not. Update holds the bulk of bugs/problems. Merge is
> > simpler as it only results in local mods.
>
> Still, do we know whether any possible merge conflicts can always
> be resolved? And that they can always be resolved without requiring
> an extremely rare diamond from a cave in South America, waterproof
> gloves, a piece of rope, and a strawberry-flavoured lollipop?
- I don't think we have any restriction on the use of "merge" or
"revert" or "resolved".
- Could be difficult to remember/discover the source URL(s) and
revision range. Issue #3322 would help a lot.
- That's all I can think of for theoretical concerns. Need to try some
more walk-throughs to check for practical problems.
> > I like what Mark said:
> > - Tree-conflicts do look good in many cases, and
> > - Tree-conflicts are *very* complex and may need to grow gradually beyond
> > 1.7 anyway.
>
> Yes, but a known-working resolution user interface would be highly
> desirable for release.
Indeed. OK, from our IRC exchange just now we're talking about ensuring
users have the pertinent info (incl. URLs and revs involved - issue
#3322) and hints in messages of what they may need to do.
Preferably we'd have "resolve --accept=old/theirs/mine" but I think
that's too ambitious for 1.6, despite being highly desirable.
> > It remains inherently difficult to form a firm opinion on it. I keep swaying
> > both ways... I think it'd be best to have preferably unknowing people to
> > take on tree-conflicts scenarios, as stsp tried, and see what they say (see
> > the thread following
> > http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=145317
> > ), in order to get very specific reasons for either decision.
> >
> > For example, it would be very helpful if any developers out there could take
> > the current trunk and carry out two complete, typical conflicting Java code
> > refactorings, and try to merge them either via "merge" or via "update",
> > including all resolve/resolved/revert steps necessary.
>
> +1
>
> In addition to having an infinite number of monkeys walk through possible
> tree conflict cases to uncover bugs and improve the user interface flow,
> we should also try to think of ways to make sure conflicts are always
> resolvable, no matter what the situation at hand, e.g. by making certain
> guarantees about information available to the user.
>
> Git handles this nicely. See Section "5.2 Detailed results for Git" in
> https://www.mi.fu-berlin.de/wiki/pub/SE/ThesesHome/thesis-tree-conflicts.pdf
> for some examples.
> Here's one:
> CONFLICT (delete/modify): alpha deleted in HEAD and modified in \
> 2cc725a7db86d3f6b05c4060924142aa5ec314d8. \
> Version 2cc725a7db86d3f6b05c4060924142aa5ec314d8 of alpha left in tree.
> Automatic merge failed; fix conflicts and then commit the result.
> [...]
> $ git status
> alpha: needs merge
> $ ls
> alpha beta epsilon/ gamma/
> $ cat alpha
> alpha, modified
> $ git ls-files --unmerged
> 100644 4a58007052a65fbc2fc3f910f2855f45a4058e74 1 alpha
> 100644 bdbcaf36d1d757776eed566cac34641de540ee83 3 alpha
> $ git cat-file blob 4a58007052a65fbc2fc3f910f2855f45a4058e74
> alpha
> $ git cat-file blob bdbcaf36d1d757776eed566cac34641de540ee83
> alpha, modified
>
> I'd say as long as we make sure that the user knows which versions of
> files involved are relevant and that the user can always get at these
> versions of the files (and run 'svn diff' against them, for example),
> there's not much of a problem.
> See also http://subversion.tigris.org/issues/show_bug.cgi?id=3322
Yeah... That's looking important. Changed the issue's priority and
milestone to 2 and 1.6-consider.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: T/C and 1.6 (was Re: Lose users?)
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Nov 18, 2008 at 04:46:30AM +0100, Neels J. Hofmeyr wrote:
> Julian suggested that it would be feasible to disable tree-conflicts
> detection upon update and leave it in for merge (I'd think it's possible
> within very short notice, a couple hours for this one). TC on update are
> inherently more complex than merge, because they need to take care about
> updating the base or not. Update holds the bulk of bugs/problems. Merge is
> simpler as it only results in local mods.
Still, do we know whether any possible merge conflicts can always
be resolved? And that they can always be resolved without requiring
an extremely rare diamond from a cave in South America, waterproof
gloves, a piece of rope, and a strawberry-flavoured lollipop?
> I like what Mark said:
> - Tree-conflicts do look good in many cases, and
> - Tree-conflicts are *very* complex and may need to grow gradually beyond
> 1.7 anyway.
Yes, but a known-working resolution user interface would be highly
desirable for release.
> It remains inherently difficult to form a firm opinion on it. I keep swaying
> both ways... I think it'd be best to have preferably unknowing people to
> take on tree-conflicts scenarios, as stsp tried, and see what they say (see
> the thread following
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=145317
> ), in order to get very specific reasons for either decision.
>
> For example, it would be very helpful if any developers out there could take
> the current trunk and carry out two complete, typical conflicting Java code
> refactorings, and try to merge them either via "merge" or via "update",
> including all resolve/resolved/revert steps necessary.
+1
In addition to having an infinite number of monkeys walk through possible
tree conflict cases to uncover bugs and improve the user interface flow,
we should also try to think of ways to make sure conflicts are always
resolvable, no matter what the situation at hand, e.g. by making certain
guarantees about information available to the user.
Git handles this nicely. See Section "5.2 Detailed results for Git" in
https://www.mi.fu-berlin.de/wiki/pub/SE/ThesesHome/thesis-tree-conflicts.pdf
for some examples.
Here's one:
CONFLICT (delete/modify): alpha deleted in HEAD and modified in \
2cc725a7db86d3f6b05c4060924142aa5ec314d8. \
Version 2cc725a7db86d3f6b05c4060924142aa5ec314d8 of alpha left in tree.
Automatic merge failed; fix conflicts and then commit the result.
[...]
$ git status
alpha: needs merge
$ ls
alpha beta epsilon/ gamma/
$ cat alpha
alpha, modified
$ git ls-files --unmerged
100644 4a58007052a65fbc2fc3f910f2855f45a4058e74 1 alpha
100644 bdbcaf36d1d757776eed566cac34641de540ee83 3 alpha
$ git cat-file blob 4a58007052a65fbc2fc3f910f2855f45a4058e74
alpha
$ git cat-file blob bdbcaf36d1d757776eed566cac34641de540ee83
alpha, modified
I'd say as long as we make sure that the user knows which versions of
files involved are relevant and that the user can always get at these
versions of the files (and run 'svn diff' against them, for example),
there's not much of a problem.
See also http://subversion.tigris.org/issues/show_bug.cgi?id=3322
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: T/C and 1.6 (was Re: Lose users?)
Posted by Branko Čibej <br...@xbc.nu>.
Stephen Butler wrote:
> The code for tree conflict detection, skipping, and status-reporting
> has matured a lot in the last few weeks.
Every time I see the phrase "code has matured," I get flashbacks to some
horrible Corsican cheese. :-P
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: T/C and 1.6 (was Re: Lose users?)
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
>>> As a thought experiment, how difficult would it be to release 1.6
>>> without tree
>>> conflicts?
>> TODO: Take out TC code and tests, restore old error messages
>> (that we replaced with TCs), and tweak old tests that create
>> TCs inadvertently.
>>
>> A few hours, I guess. I think we could safely plan to branch
>> Wednesday evening.
I humbly disagree, I think it would take a little longer than that. The
tests mending alone would be quite stupendous and time-consuming. I'd say
three days at least?
> Whoa, pard'ner! My comments were a bit drastic, too be sure, so I hope you're
> not now frantically working to pull every shred of tree conflicts from 1.6. I'm
> just curious as to what the effort would be.
>
> And note that when I say "pull tree conflicts" I really mean "remove the bits
> which aren't finished and which couldn't ship Real Soon Now."
Julian suggested that it would be feasible to disable tree-conflicts
detection upon update and leave it in for merge (I'd think it's possible
within very short notice, a couple hours for this one). TC on update are
inherently more complex than merge, because they need to take care about
updating the base or not. Update holds the bulk of bugs/problems. Merge is
simpler as it only results in local mods.
I like what Mark said:
- Tree-conflicts do look good in many cases, and
- Tree-conflicts are *very* complex and may need to grow gradually beyond
1.7 anyway.
I feel that we've been hunting corner cases in tree-conflicts for a long
time now. The core works. The problem being the vast number of possible
corner cases. And in some cases "what happens after" is still unanswered.
It remains inherently difficult to form a firm opinion on it. I keep swaying
both ways... I think it'd be best to have preferably unknowing people to
take on tree-conflicts scenarios, as stsp tried, and see what they say (see
the thread following
http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=145317
), in order to get very specific reasons for either decision.
For example, it would be very helpful if any developers out there could take
the current trunk and carry out two complete, typical conflicting Java code
refactorings, and try to merge them either via "merge" or via "update",
including all resolve/resolved/revert steps necessary.
We are happy to assist. It would be good if someone out there did this,
deliberately trying to get as confused as possible, because us TC folks know
too much about tree-conflicts to be impartial.
Thanks!
~Neels
Re: T/C and 1.6 (was Re: Lose users?)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Stephen Butler wrote:
> Quoting "Hyrum K. Wright" <hy...@mail.utexas.edu>:
>
>> After talking with Karl in IRC just now, my view is kind of changing:
>>
>> Let's yank the APIs now, branch 1.6.x at the end of the week,
>> stabilize, and
>> release 1.6 with the currently implemented features.
>
>> I think the trepidation to yank the tree conflicts APIs for 1.6 comes
>> from the
>> innate emotional attachment developers tend to have to their own code
>> and a
>> desire to see it ship.
>
> Guilty as charged, your honor. ;-) I also tend to focus too closely
> on short term goals and the next patches, and lose perspective on the
> medium-term issues that really block this feature from release.
Completely natural tendency. ("I want *my* code to ship, so if 1.6 ships sooner
if we remove tree conflicts, let's do that!") I'm just trying to make sure I've
got a complete idea of where we stand.
> The code for tree conflict detection, skipping, and status-reporting
> has matured a lot in the last few weeks. But I'm afraid our design
> for resolve and revert is still rather sketchy. We hadn't realized
> how tricky it is to resolve tree conflicts. And helping the user
> by offering "mine-full", "theirs-full", etc. will take APIs and
> infrastructure that are difficult to shoehorn into the current
> piecemeal-admin-area architecture.
So, would the resolving bits need to wait until WC-NG? It sounds like not being
able to revert may be a bit of problem, but maybe I just don't understand the
problem in it's entirety.
> Leaving users to detect tree conflicts on their own isn't an ideal
> solution, either, but at least we won't be in trouble for blocking
> their commits!
>
> Tree conflict fans, do you agree?
>
>> As a thought experiment, how difficult would it be to release 1.6
>> without tree
>> conflicts?
>
> TODO: Take out TC code and tests, restore old error messages
> (that we replaced with TCs), and tweak old tests that create
> TCs inadvertently.
>
> A few hours, I guess. I think we could safely plan to branch
> Wednesday evening.
Whoa, pard'ner! My comments were a bit drastic, too be sure, so I hope you're
not now frantically working to pull every shred of tree conflicts from 1.6. I'm
just curious as to what the effort would be.
And note that when I say "pull tree conflicts" I really mean "remove the bits
which aren't finished and which couldn't ship Real Soon Now."
-Hyrum
Re: T/C and 1.6 (was Re: Lose users?)
Posted by Stephen Butler <sb...@elego.de>.
Quoting "Hyrum K. Wright" <hy...@mail.utexas.edu>:
> After talking with Karl in IRC just now, my view is kind of changing:
>
> Let's yank the APIs now, branch 1.6.x at the end of the week, stabilize, and
> release 1.6 with the currently implemented features.
> I think the trepidation to yank the tree conflicts APIs for 1.6
> comes from the
> innate emotional attachment developers tend to have to their own code and a
> desire to see it ship.
Guilty as charged, your honor. ;-) I also tend to focus too closely
on short term goals and the next patches, and lose perspective on the
medium-term issues that really block this feature from release.
The code for tree conflict detection, skipping, and status-reporting
has matured a lot in the last few weeks. But I'm afraid our design
for resolve and revert is still rather sketchy. We hadn't realized
how tricky it is to resolve tree conflicts. And helping the user
by offering "mine-full", "theirs-full", etc. will take APIs and
infrastructure that are difficult to shoehorn into the current
piecemeal-admin-area architecture.
Leaving users to detect tree conflicts on their own isn't an ideal
solution, either, but at least we won't be in trouble for blocking
their commits!
Tree conflict fans, do you agree?
> As a thought experiment, how difficult would it be to release 1.6
> without tree
> conflicts?
TODO: Take out TC code and tests, restore old error messages
(that we replaced with TCs), and tweak old tests that create
TCs inadvertently.
A few hours, I guess. I think we could safely plan to branch
Wednesday evening.
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
T/C and 1.6 (was Re: Lose users?)
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Justin Erenkrantz wrote:
> On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Producing some kind of definition of the remaining tree conflicts work for 1.6
>> will help the community understand what's left to do, and more importantly help
>> the tree-conflicts folks understand what's left. It may even get a few more
>> people involved if there are well-scoped bite-sized tasks available.
>>
>> Neels, Stefan, Julian, et al: I await your list of what's left. :)
>
> My suggestion from the peanut gallery is:
>
> 1) We should await a review of what is 'left' on tree conflicts
> 2) Ensure ourselves as a community that it is doable within <1 mo of work
> 3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
> 4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
> releases, but just ensuring dev@ is happy with it)
> 5) Merge approved backports and whatever is on the list of to-do for
> tree conflicts
> 6) Once tree conflicts is API-stable, begin formal stabilization procedures
>
> My point is really that we begin the stabilization of the rest of the
> code as soon as possible, get trunk back to be open (waves bye-bye to
> ra_neon *grin*), and merge tree conflicts stuff and start the final
> stabilization as soon as it's API-stable.
>
> If the tree conflicts stuff can't be resolved within 1 mo or it takes
> longer than that, then we yank the APIs for 1.6.x and it continues
> apace for 1.7.x and we release 1.6.x without it. (I'm okay with
> shipping dead code if it makes the RM process simpler as long as it
> doesn't expose any APIs.)
After talking with Karl in IRC just now, my view is kind of changing:
Let's yank the APIs now, branch 1.6.x at the end of the week, stabilize, and
release 1.6 with the currently implemented features.
We want to delay 1.6 so that people can get tree conflicts sooner, implying that
a soonish 1.6 is better than waiting a few months beyond that for 1.7. But we
forget that we've got a lot of stuff already in 1.6, some work needed to
stabilize that work, and good motivation to get that out to users right now.
I think the trepidation to yank the tree conflicts APIs for 1.6 comes from the
innate emotional attachment developers tend to have to their own code and a
desire to see it ship. I also think that there may be a voice in many people's
minds that says "we need to get tree conflicts in 1.6, because we still don't
know if our time-based releases will work out and 1.7 will be soon after 1.6."
As hokey as it sounds, we need to exercise some faith in our process, release
1.6, and know that 1.7 will be coming soon.
As a thought experiment, how difficult would it be to release 1.6 without tree
conflicts?
-Hyrum
Re: Lose users? -- was: Re: Update on my previous tree conflict
scenario
Posted by Julian Foad <ju...@btopenworld.com>.
On Mon, 2008-11-17 at 10:37 -0600, Justin Erenkrantz wrote:
> On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
> > Producing some kind of definition of the remaining tree conflicts work for 1.6
> > will help the community understand what's left to do, and more importantly help
> > the tree-conflicts folks understand what's left. It may even get a few more
> > people involved if there are well-scoped bite-sized tasks available.
> >
> > Neels, Stefan, Julian, et al: I await your list of what's left. :)
>
> My suggestion from the peanut gallery is:
>
> 1) We should await a review of what is 'left' on tree conflicts
See new thread "Tree conflicts - What's To Do".
I need help to turn a list of issues into a plan. Anybody?
One thing we should do to organise the list is enter the TODO-1.6 items
into the issue tracker (with "1.6" target milestone) and the mailing
list items (with "1.6-consider") so they're all in one place.
- Julian
> 2) Ensure ourselves as a community that it is doable within <1 mo of work
> 3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
> 4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
> releases, but just ensuring dev@ is happy with it)
> 5) Merge approved backports and whatever is on the list of to-do for
> tree conflicts
> 6) Once tree conflicts is API-stable, begin formal stabilization procedures
>
> My point is really that we begin the stabilization of the rest of the
> code as soon as possible, get trunk back to be open (waves bye-bye to
> ra_neon *grin*), and merge tree conflicts stuff and start the final
> stabilization as soon as it's API-stable.
>
> If the tree conflicts stuff can't be resolved within 1 mo or it takes
> longer than that, then we yank the APIs for 1.6.x and it continues
> apace for 1.7.x and we release 1.6.x without it. (I'm okay with
> shipping dead code if it makes the RM process simpler as long as it
> doesn't expose any APIs.)
>
> My $.02. -- justin
Thanks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Producing some kind of definition of the remaining tree conflicts work for 1.6
> will help the community understand what's left to do, and more importantly help
> the tree-conflicts folks understand what's left. It may even get a few more
> people involved if there are well-scoped bite-sized tasks available.
>
> Neels, Stefan, Julian, et al: I await your list of what's left. :)
My suggestion from the peanut gallery is:
1) We should await a review of what is 'left' on tree conflicts
2) Ensure ourselves as a community that it is doable within <1 mo of work
3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
releases, but just ensuring dev@ is happy with it)
5) Merge approved backports and whatever is on the list of to-do for
tree conflicts
6) Once tree conflicts is API-stable, begin formal stabilization procedures
My point is really that we begin the stabilization of the rest of the
code as soon as possible, get trunk back to be open (waves bye-bye to
ra_neon *grin*), and merge tree conflicts stuff and start the final
stabilization as soon as it's API-stable.
If the tree conflicts stuff can't be resolved within 1 mo or it takes
longer than that, then we yank the APIs for 1.6.x and it continues
apace for 1.7.x and we release 1.6.x without it. (I'm okay with
shipping dead code if it makes the RM process simpler as long as it
doesn't expose any APIs.)
My $.02. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Greg Stein wrote:
> On Sat, Nov 15, 2008 at 8:00 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
>> Greg Stein wrote:
>>> Personally, I would give the tree conflict folks until first/second
>>> week of January (i.e. just post-break) to wrap their work. And by
>>> "wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
>>> to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
>>> them the *proper* time to get the work done and make it solid. I fear
>>> that putting this feature "under the gun" will be a bad outcome for
>>> everybody. It also seems to be reasonable/close enough that we can
>>> take a month or two to get it wrapped (or cut, worst case).
>> When you say EOY, then that's a whole new story. I was expecting the
>> branching to take place tomorrow-ish, us handing in patches onto the branch
>> and having to release before christmas. If we can carry on developing "on
>> trunk" until christmas, I think that we'll have sufficient tree-conflicts
>> usability for a release. Tree-conflicts folks, do you agree?
>
> Note that that is only my opinion. You've gotta convince others to go
> that long :-)
>
> Further, I'm good with that only when knowing "what is left? how do we
> cut if necessary?" types of questions. In other words, it isn't an
> open-ended ticket to churn :-) Some kind of feature description of
> what is in/out is still needed -- do you guys really have a handle on
> this? Or are we going to continue to bumble along until one day it is
> called "done".
I completely agree here. The mistake with 1.5 wasn't that it included merge
tracking or that merge tracking was hard; the mistake was an unclear notion of
the scope of the problem and the complexity of the solution, in spite of having
some very bright people working on it.
Producing some kind of definition of the remaining tree conflicts work for 1.6
will help the community understand what's left to do, and more importantly help
the tree-conflicts folks understand what's left. It may even get a few more
people involved if there are well-scoped bite-sized tasks available.
Neels, Stefan, Julian, et al: I await your list of what's left. :)
> I don't really care about the "hard" December date. A month or two is
> fine. We want good, and we want stable. Hard rules tend to work
> against those goals.
As RM, I just oversee the release process, but I let the community decide what
that process is and when it should be kicked off. That said, as a developer,
I'm happy to let the branch date slide *a little* if it facilitates more
stability. However, we need to be very careful, because many "a little"s adds
up to "a lot".
-Hyrum
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Greg Stein wrote:
> On Sat, Nov 15, 2008 at 8:00 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
>> Greg Stein wrote:
>>> Personally, I would give the tree conflict folks until first/second
>>> week of January (i.e. just post-break) to wrap their work. And by
>>> "wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
>>> to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
>>> them the *proper* time to get the work done and make it solid. I fear
>>> that putting this feature "under the gun" will be a bad outcome for
>>> everybody. It also seems to be reasonable/close enough that we can
>>> take a month or two to get it wrapped (or cut, worst case).
>> When you say EOY, then that's a whole new story. I was expecting the
>> branching to take place tomorrow-ish, us handing in patches onto the branch
>> and having to release before christmas. If we can carry on developing "on
>> trunk" until christmas, I think that we'll have sufficient tree-conflicts
>> usability for a release. Tree-conflicts folks, do you agree?
>
> Note that that is only my opinion. You've gotta convince others to go
> that long :-)
Yes, everyone else, note that I am until now only asking tree-conflicts
folks if they have the same impression that I have about how much time would
be needed, so that you guys out there can have opinions on it.
>
> Further, I'm good with that only when knowing "what is left? how do we
> cut if necessary?" types of questions. In other words, it isn't an
> open-ended ticket to churn :-) Some kind of feature description of
> what is in/out is still needed -- do you guys really have a handle on
> this? Or are we going to continue to bumble along until one day it is
> called "done".
>
> I don't really care about the "hard" December date. A month or two is
> fine. We want good, and we want stable. Hard rules tend to work
> against those goals.
In my hacking career so far, I've only ever seen a single deadline being
*made*. A prof of mine once said that engineers are usually off their own
deadline estimates by a factor of three. I can relate to that. :P
Ok, let's give the other tree-conflicts folks some time to respond before we
start rolling out any more conditional replies. Steve? Julian? It seems
you've got a bigger picture of tree-conflicts than I do.
Thanks
~Neels
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Nov 15, 2008 at 8:00 PM, Neels J. Hofmeyr <ne...@elego.de> wrote:
> Greg Stein wrote:
>> Personally, I would give the tree conflict folks until first/second
>> week of January (i.e. just post-break) to wrap their work. And by
>> "wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
>> to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
>> them the *proper* time to get the work done and make it solid. I fear
>> that putting this feature "under the gun" will be a bad outcome for
>> everybody. It also seems to be reasonable/close enough that we can
>> take a month or two to get it wrapped (or cut, worst case).
>
> When you say EOY, then that's a whole new story. I was expecting the
> branching to take place tomorrow-ish, us handing in patches onto the branch
> and having to release before christmas. If we can carry on developing "on
> trunk" until christmas, I think that we'll have sufficient tree-conflicts
> usability for a release. Tree-conflicts folks, do you agree?
Note that that is only my opinion. You've gotta convince others to go
that long :-)
Further, I'm good with that only when knowing "what is left? how do we
cut if necessary?" types of questions. In other words, it isn't an
open-ended ticket to churn :-) Some kind of feature description of
what is in/out is still needed -- do you guys really have a handle on
this? Or are we going to continue to bumble along until one day it is
called "done".
I don't really care about the "hard" December date. A month or two is
fine. We want good, and we want stable. Hard rules tend to work
against those goals.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Greg Stein wrote:
> Personally, I would give the tree conflict folks until first/second
> week of January (i.e. just post-break) to wrap their work. And by
> "wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
> to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
> them the *proper* time to get the work done and make it solid. I fear
> that putting this feature "under the gun" will be a bad outcome for
> everybody. It also seems to be reasonable/close enough that we can
> take a month or two to get it wrapped (or cut, worst case).
When you say EOY, then that's a whole new story. I was expecting the
branching to take place tomorrow-ish, us handing in patches onto the branch
and having to release before christmas. If we can carry on developing "on
trunk" until christmas, I think that we'll have sufficient tree-conflicts
usability for a release. Tree-conflicts folks, do you agree?
~Neels
Re: Lose users? -- was: Re: Update on my previous tree conflict scenario
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Nov 15, 2008 at 5:58 PM, Branko Čibej <br...@xbc.nu> wrote:
> Neels J. Hofmeyr wrote:
>...
>> Should we maybe think of a Plan B? What parts of tree-conflicts handling
>> could just be disabled so that 1.6 becomes stable without removing
>> tree-conflicts altogether?
I'd posit that "most of us" cannot answer that question. "You guys"
need to figure out where to can cut/splice when push comes to shove.
What can be trimmed or unimplemented, while leaving some/most of the
good code? Where are the fringes that can be tied off?
Worst case, how does it all get disabled? For example, maybe it is "as
simple" as leaving all the code in there, but anything that *sets* the
tree conflict markers just gets disabled. Therefore, none of the
conflict code ever triggers cuz a conflict is never recorded. (of
course, this might not work if *other* types of conflict were merged
into the tree conflict code, so we need all that now)
>> What are your views, everyone...
>
> I think it is *always* better to say, "sorry, we couldn't do this in the
> time available", rip out an unstable feature, and roll 1.6 with the
> other improvements already on trunk; than to have to keep apologizing
> for either delaying the release, or shipping a crap implementation.
Agreed. I'd suggest a time-bound.
People keep holding up "December release" as some mighty Must
Accomplish. Seriously, that isn't a holy grail. We *can* easily slip
to January or Feburary. No big deal. What we DON'T WANT is to slip to
December of NEXT YEAR.
So. I'd suggest that the tree conflict folks need to come up with a
schedule here. What is the likely outcomes here? What time frames are
likely to be associated with those?
Obviously, this is called "Research & Development" for a reason.
Something can always come up. But when it is *likely* to be finished?
What sections can remain unimplemented? What is the final set of
features? *SOME* kind of idea is needed here, along with various
triage options.
I'd suggest the tree conflict folks focus on four possible plans:
* cut it out altogether so we can ship "now"
* code/cut to fit a ONE WEEK stabilization timeline
* code/cut to fit a three week timeline
* code/cut to fit end-of-year timeline
The one week means "wrap it now and we'll definitely hit EOY release".
Three weeks is "we might hit EOY". EOY release obviously means end of
January or so.
Personally, I would give the tree conflict folks until first/second
week of January (i.e. just post-break) to wrap their work. And by
"wrap", I mean finish or cut. I think it is TOTALLY acceptable for us
to ship 1.6 in a Jan/Feb timeframe, so I'm more than willing to give
them the *proper* time to get the work done and make it solid. I fear
that putting this feature "under the gun" will be a bad outcome for
everybody. It also seems to be reasonable/close enough that we can
take a month or two to get it wrapped (or cut, worst case).
Cheers,
-g
Re: Lose users? -- was: Re: Update on my previous tree conflict
scenario
Posted by Branko Čibej <br...@xbc.nu>.
Neels J. Hofmeyr wrote:
> Stefan Sperling wrote:
>
>> On Sat, Nov 15, 2008 at 10:21:49AM +0200, Daniel Shahaf wrote:
>>
>>> Neels J. Hofmeyr wrote on Sat, 15 Nov 2008 at 04:10 +0100:
>>>
>>>> And the same for merge. Further guidance from `svn info':
>>>>
>>>> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
>>>> <Info stuff>
>>>> <Tree conflict stuff> You have edited file foo but an update tried to
>>>> delete, possibly as part of a move.
>>>> <In case of D -> M, also show this:>
>>>> Hint: This kind of conflict may require `svn revert' to be resolved. Do
>>>> make sure that your local modifications are copied somewhere safe first.
>>>>
>>>>
>>> I wouldn't mind having this info somewhere (svn resolve --show-suggestions
>>> victim_path), but I suspect any kind of "hint" shown by default will
>>> eventually get annoying (once I know what it's going to say). Hard to say
>>> without having seen it in practice (during my work), though.
>>>
>> The problem is: We ourselves don't even know how to resolve each
>> individual conflict in the entire set of possible tree conflicts.
>> We've never tried to resolve them all.
>>
>> I am all +1 on adding some form of guidance to the UI,
>> see the "tree conflicts from user's point of view" thread:
>> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=145339
>>
>> But I think it's a bad idea to start putting hints in the UI without
>> having a proper plan mapped out on how we can treat each individual
>> conflict scenario, or without knowing whether there is some general way
>> that will be able to deal with any possible scenario.
>>
>> The inconsistencies and weirdness people are seeing in the UI
>> are real problems. We have to fix those. So far, most of the tree
>> conflicts work was about detection and preventing commits. That
>> seems to work fine now.
>>
>> The 'svn status' interface is still under discussion, and certainly
>> a very important part of the UI:
>> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=14432
>>
>> Another UI discussion is here:
>> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142893
>> but note how 'svn resolve' is being hinted at but left unspecified at the
>> end of that mail (we only ever talked about 'svn resolveD' AFAIK).
>>
>> I have started walking through some cases in the "tree conflicts from
>> user's point of view" thread linked above, just to see what the experience
>> is like with the current state of things. I would like to encourage people
>> to pick a scenario and walk through it, evaluating how to resolve the
>> conflict, for each possible desired merge result if time permits, and
>> state what they liked about the experience and what they didn't like.
>> Feedback by developers or advanced users who have never concerned
>> themselves with tree conflicts before would be most valuable.
>>
>> I have a couple of scripts that produce tree conflict scenarios to
>> work with, so you don't have to make up your own scenarios:
>> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=15317
>> You can use these scripts easily if you have a current trunk
>> build in your shell's PATH. Sorry, I don't have windows versions
>> of these scripts, so you need cygwin or a unix-like OS to run them.
>>
>> I know it's tedious to walk through these cases, but if we don't
>> critically examine and improve our current tree conflicts UI before
>> release and end up shipping the release with a bad UI, my intuition
>> is that people will complain as badly as they are complaining about
>> the current merge-tracking problems in 1.5.x.
>>
>> We can use a lot of users over this if we don't get this right.
>>
>
> You mean "lose".
>
> Yes, I agree. I'm seeing some parallels to the bad experiences described in
> Hyrum's paper that was recently posted to the committers list. It feels like
> we are again defining 1.6 as "the release that can handle tree-conflicts",
> while we are at a point in time where tree-conflicts should ideally be
> stable (as of last Wednesday), but instead we're stumbling across newly
> discovered bugs (and even a design flaw once) on a pretty much regular basis.
>
> We might well be able to stabilize tree-conflicts stuff in a matter of
> weeks. Then again, we might not! That would mean we are repeating 1.5, while
> everyone was saying "we *must not* repeat 1.5".
>
> Needless to say that a bunch of people (probably including my employers)
> would be awfully pissed off if tree-conflicts didn't make it into 1.6. But
> what about the big rest of Subversion use, at large?
>
> Should we maybe think of a Plan B? What parts of tree-conflicts handling
> could just be disabled so that 1.6 becomes stable without removing
> tree-conflicts altogether?
>
> What are your views, everyone...
>
I think it is *always* better to say, "sorry, we couldn't do this in the
time available", rip out an unstable feature, and roll 1.6 with the
other improvements already on trunk; than to have to keep apologizing
for either delaying the release, or shipping a crap implementation.
With 1.5 and merge tracking, it appears we did both. :)
So I suggest: disable tree conflicts (if that means branching trunk
again and physically ripping out the code, that's fine); and release a
stable 1.6.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org