Finalizing what's in 1.5 (was: Getting closer to a 1.5 release?)
From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 10 Jan 2008 13:38:47 -0800
Karl Fogel <kfogel_at_red-bean.com> writes:
Okay, we just had a long IRC conversation about this (see transcript
1. The #2897 (reflective merges) branch. Do we need to ship with
This possibility is no slight on Kamesh, by the way: he's
This is the major outstanding question for 1.5. We need to
2. Related to the above: there's the question of whether that
3. Finishing up and merging the reintegrate branch. glasser and I
4. Solution to the 'cp -g' conundrum: well, we came to a pretty
5. 'log -g' and 'blame -g' need to be fixed; hwright and cmpilato
In summary: our biggest open question is #2897. We really need to
Here's the IRC transcript:
<kfogel> So I see a few major questions still outstanding:
<kfogel> 1. Is the #2897 work going into 1.5?
<kfogel> 2. If so, will it depend on SQLite or not?
<kfogel> 3. (related) Are we trying to ship without SQLite dep?
<markphip> 3. we need it for the node origins cache
<kfogel> 4. How much work left on reintegrate branch?
<kfogel> (I'll say "EOT" when done listing, btw.)
<glasser> markphip: no we don't, that's dirt simple to reimplement
<kfogel> 5. The 'cp -g' situation. This is more of a plain
<glasser> hwright: dannyb was suggesting otherwise when i saw him
<markphip> glasser: excellent!
<kfogel> 6. log -g and blame -g need to be fixed, but that seems
<kfogel> Okay, EOT.
<kfogel> Is that list missing anything major?
<hwright> glasser: yay for subversion!
<kfogel> (Of course, there's the 19 or so issues marked "1.5" in
<hwright> (the process, not the software)
<markphip> Since you gave EOT ... is 5 still an issue? I thought
<kfogel> markphip: yes, it's still an issue.
<glasser> 1: Um. I can't tell to what degree Kamesh's branch is "an
<kfogel> Before I go into details why, I'd like to get overall
* kfogel was referring to cp -g just now
<markphip> I was under the impression glasser knew how to remove the
<kfogel> glasser: that's what I'm worried about. My instinct is
<glasser> 2: I think I can make it not depend on SQLite. And if we
<kfogel> whew -- both halves of that statement are reassuring
<glasser> kfogel: Yeah. Like, the core of what he's doing is
<kfogel> glasser: I'm sorry so much is on your shoulders, btw :-(.
<markphip> the node origins cache seems pretty critical for
<glasser> 3: I don't care about deps or not, I just care about using
<kfogel> *nod* ok
<glasser> kfogel: Oh, understood. And I'm spending a bit of time on
<markphip> 3. I agree. having the dep is not the issue
<glasser> 4: I dunno, I think we're almost ready to merge back. I
<markphip> removing it would be great of course
<glasser> Though I haven't looked at our TODOs in the past couple of
<kfogel> ok -- looks like I was more concerned about the pure
<kfogel> glasser: I'm chipping away at them, but I think I will
<markphip> I think a lot of people mistook the work glasser was doing
<glasser> 5: Well, we have a current decision. cmpilato even added
<kfogel> markphip: (yes, that may have happened.)
<markphip> has there been any recent threads about cp -g ? I really
<kfogel> Okay, here is my understanding about cp -g:
<kfogel> (and I'll check this with cmpilato after I type it, as
<glasser> He removed the need. In return we get "mergeinfo gets
<kfogel> Currently, 'svn cp' with no '-g' will be a purely local
* kfogel checks with cmpilato now
<kfogel> Mike says he removed the option entirely!
* kfogel listens to mike
<glasser> Dumb question: how did "cp -g" ever even work? Wouldn't
<markphip> it is based on what you copied though, right? And there
<kfogel> Mike and I are settling on a solution here; it might be
<markphip> Issue 2897 is our only remaining P1
<kfogel> I'm not going to go into details of what 'svn cp -g' *did*
<kfogel> But Mike and I propose this:
<kfogel> (one sec, sorry)
<kfogel> mike is joining
<kfogel> typa typa typa
<cmpilato> Here's the proposal: we never re-add -g to 'svn cp';
<kfogel> (the priority this proposal is aiming for, as soon as mike
<cmpilato> yes, this changes the default behavior of 'svn cp WC WC'
<cmpilato> no, we don't care.
<kfogel> Amen. bikeshed: --local-mergeinfo-only for the opt, but
<cmpilato> because we value correctness, and merge tracking is a big
<glasser> If we can wrap the "can't contact server" error in a "try
<kfogel> (glasser: after this discussion, I have a couple of quick
* cmpilato doesn't like the current do-the-best-you-can behavior.
<pburba >if we really don't care then about the change in default
<glasser> (I mean, the big downside is if the "svn cp" is actually
<cmpilato> yes, that's true, but none of our subcommands ever
<kfogel> I think we sort of care, but not enough to tolerate
<cmpilato> we aren't violating promises in this way.
<hwright> so, would 'svn cp' still create mergeinfo? or would the
<cmpilato> that some commands didn't need to contact the repo before
<kfogel> (and note that we're free to *restore* local-only behavior
<cmpilato> 'svn cp' would not *create* mergeinfo; though it might
<kfogel> glasser: for "some tool", read "TortoiseSVN", and we work
<markphip> would it always contact the repository?
<cmpilato> svn cp would always contact the repository unless
<markphip> I thought people considered that not acceptable?
<cmpilato> i was one of those people.
<glasser> kfogel: Tortoise is fine, I'm thinking of other things
<cmpilato> people change.
<glasser> If the answer is "these people need to rewrite their
<kfogel> glasser: yeah, there will be fallout. But having
<kfogel> because the latter is a time bomb, where as the former
<markphip> I'm slightly less convinced
<kfogel> now, that error will only come after an N-second or
<pburba >cmpilato: We'd contact the repos even if the copied source
<markphip> if the information is potentially critical, then I am not
<kfogel> markphip: we can potentially fix this decision in later
<cmpilato> pburba: oh! good point! no, that'd be silly.
<kfogel> markphip: I agree that would be a better solution, but
<pburba >cmpilato: I think the if the copy source has a WC parent
<cmpilato> pburba: but i'm not sure we can trust anything other than
<cmpilato> oh. heh. you were in the same town i was, there.
<cmpilato> i'd feel much better about saying outright "we only trust
<cmpilato> much less fuzzy and complex to explain to folks.
* pburba meant "no need to copy" -->"no need to contact repos" if that wasnt obvious
<markphip> kfogel: thanks, that is a good point. This solution could
<kfogel> very much, yeah
<glasser> kfogel: Oh! I have a super huge reason why this change is
<kfogel> hit us!
<glasser> kfogel: because otherwise every wc-wc copy (which in
<glasser> which breaks --reintegrate :)
* kfogel ponders that
<kfogel> every one?
<glasser> maybe not quite every
<cmpilato> even same-dir copies?
<glasser> (for the record, I am still of the opinion of "if you ever
<glasser> (eg, "open source projects smaller than mozilla shouldn't
<kfogel> glasser: I think that's probably true almost always, sure.
<kfogel> okay, it sounds like we have a general agreement here,
<glasser> (Or to put it another way: the metnal model of mergeinfo
<markphip> help me out here ... I am working in one of these "sane
<glasser> I'm lunching soon though
<kfogel> glasser: oh, let's answer markphip first, I can hit you up
<kfogel> better to get to the bottom of cp questions
<kfogel> markphip: I believe the answer is the explicit empty
<kfogel> I am SO not sure about that, though.
<kfogel> or rather, explicit mergeinfo that either preserves the
<kfogel> it doesn't want to inherit from the new parent, since that
* kfogel waits for someone to tell him he's insane
<markphip> I ask because I do not think simple open source projects
<kfogel> well, copying isn't strange or wrong
<kfogel> subversion should do the right thing w/ mergeinfo under
<glasser> markphip: i think the easy answer is "if all mergeinfo is
<markphip> if it creates mergeinfo that makes things look like you
<kfogel> markphip: not sure what you maen
<markphip> glasser: well that is what I am getting at then. Are we
<markphip> kfogel: if we create mergeinfo on the files, it starts to
<markphip> when all they really did was "normal" development
<markphip> we ideally want a system that encourages and preserves
<kfogel> markphip: I think glasser's point is that contacting the
<kfogel> Which I agree with, if that's what he's saying.
<markphip> kfogel: right, and that was really what my original
<kfogel> (Heck, I agree with it even if he's not saying it!)
<markphip> I agree that should be our goal
<kfogel> so the answer satisfies you, I'm presuming :-)
<markphip> if the root of your WC is the only place that contains
<kfogel> glasser: I'll hit you up after lunch about the reint stuff
<markphip> too much to check?
<kfogel> (and then I think I'll be ready to post a State of the
<hwright> kfogel: re 6: there may be a bit of design work, now that
<kfogel> markphip: I think the deal is, there are some
<hwright> but I don't think it to be overly complex.
<kfogel> hwright: ooooh. uh, okay (shiver)
<kfogel> I hear "design work" and worry.
<kfogel> You're talking about blame, not log?
<hwright> well, not *that* kind of design work, more like "how does
<kfogel> ah, okay
<hwright> both will need a look-see.
<hwright> witness the failing blame test on trunk right now. :(
<kfogel> I think enough information has been gathered here. I'm
<kfogel> hwright: *nod* this is separate from the 'log -g output
<hwright> seperate, but that discussion is related.
<kfogel> (There, I think the final answer is that our non-xml
<hwright> because we can't filter history in front of branching
<kfogel> s/in front of/earlier than/ ?
<kfogel> there might be ways the client could bunch stuff up and
<hwright> yup. cmpilato and I had a conversation about this last
<hwright> we were both pretty tired, though, so the details are a
<kfogel> brain full, stomach empty
<kfogel> back l8r
This is an archived mail posted to the Subversion Dev mailing list.