Ticket #462 (closed enhancement: fixed)

Opened 4 years ago

Last modified 4 years ago

Mercurial clobber for changing branch

Reported by: even Owned by: even
Priority: major Milestone: 0.7.11
Version: 0.7.10 Keywords: review
Cc: fqueze,marcusl

Description

Right now, each time we want to change branch, we clobber the whole repository. That is not needed...

We might prefer to use a simpler an quicker sequence if the branch is not correct like : hg update --clean --rev branchName

Whatever, the person doing the compilation might clobber himself or delete symbols if needed but forcing it is not a very good approach.

I'll try to issue a patch about that as quickly as possible (in my situation, that clobber might cause me 1 hour and a half building time on windows... it is not really affordable).

Attachments

change_branch_with_update.patch Download (1.0 KB) - added by even 4 years ago.
First version of the patch. Tested on win32.
v2.patch Download (3.3 KB) - added by even 4 years ago.
Patch bug462 branch to add clobberOnBranchChange

Change History

Changed 4 years ago by even

First version of the patch. Tested on win32.

comment:1 Changed 4 years ago by even

  • Keywords review added
  • Status changed from new to assigned

comment:2 Changed 4 years ago by marcusl

Hm. I understand you concern. However, I'm a bit wary with leaving stuff in there as well. Also, the current buildbot tests fail if the sourcestep does not clobber when the branch change. Perhaps that is unwarranted, but I didn't want to change the tests behaviour when I wrote the inrepo-test for Mercurial, so I added the clobber check to the source step.

Is the problem that the clone takes time, or the subsequent build, or both?

If only the former, perhaps solving #412 would help? IIUC, that would make test pass, while leave the local .hg dir intact, thus avoiding the expensive re-clone.

If the latter, I would want the patch to make the behaviour switchable, as I like my buildsteps to do the right thing, always.

What do you think?

comment:3 Changed 4 years ago by even

About the time problematics, I think that the first problem, checkout time, is the worst of them. We are whatsoever deleting objects when changing branches, at least for each important builds.

And yes, solving #412 would be another way to solve that issue, at least if the purge extension is present. But I would like to point out that mercurial seems to handle very well its files and there should be no problem in updating from one branch to another without clobbering. But if, in a specific scenario of an user, there is a risk, he might ask for clobber himself knowing of his situation. I don't understand why we would want to impose the clobbering to the user here.

Maybe we can also add an option for that like "clobberOnBranchChange" that might defaults to False but might be needed in very specific scenario.

comment:4 Changed 4 years ago by marcusl

Ok. I'm basically fine with changing it, but this causes a regression in the tests. (buildbot.test.test_vc.MercurialInRepo?.testBranch fails)

If we still want to do this, we need to change the test. For that, we need some input from some of the more senior developers who wrote the thing in the first place (i.e. Brian or Dustin).

We could also, instead of the overly brutal clobber, just delete everything except the .hg dir, then update again. That would be a middle-ground, and a good fallback for #412.

I've made a branch from the main repo (djmitche/master) and added your patch (slightly modified as we've added clobber on dirname-branching) here:

 http://github.com/marcusl/buildbot/tree/bug462

We can't merge to main until the tests run cleanly. I'll ask the mail-list for opinions here.

comment:5 Changed 4 years ago by marcusl

comment:6 Changed 4 years ago by even

Thanks for the quick feedback (as always, but I never took the time to say how much I appreciate that !).

I wrote a modification of my previous patch to add the clobberOnBranchChange argument. Since it's a bit late now, I'll try it only tomorrow. If that works I will put the patch here and look the test suite to see how we can fix those.

I'll maybe take some time to solve #412 too since it looks promising. If I get #412 ready and tests running, we might think about having clobberOnBranchChange defaulting to True instead of False.

We're also going to have to fix documentation and advise people to activate purge extension and/or setting clobberOnBranchChange to False if they have big repositories.

comment:7 Changed 4 years ago by even

I just thought about it. The clobber is necessary on dirname branching. clobberOnBranchChange is a possibility only if using inrepos branches, just as the purge extension. We need to clobber to get rid of the whole folder if using dirname branching.

That's probably for that case that clobbering was requested to change branch on previous implementations.

I'll try to do a nice patch tomorrow.

comment:8 Changed 4 years ago by even

  • Keywords review removed

Removing the review flag, it's far from correct right now. There's quite a lot of work to do for this bug.

comment:9 Changed 4 years ago by marcusl

I didn't touch clobber on dirname branching. That should still work correct, as before.

It should be trivial to change the clobber assignment on inrep-branch-change (that I commmented out in the  commit) to use a 'clobberOnBranchChange' flag, once that is present in the mercurial slave command.

If you're able, you could create your own fork off my github repo on github and work there. Collaboration is a bit easier and simplifies for me or Dustin to merge the change into mainstream once everyone is satisfied. (If you're reasonably comfortable with git, that is.)

For #412, I'd like the fallback as well. I could help out with that. And yes, we should fix the documentation.

Changed 4 years ago by even

Patch bug462 branch to add clobberOnBranchChange

comment:10 Changed 4 years ago by even

Here is the argument we talked about. I think this works. I don't know what addFactoryArguments do so I didn't add it there but it's probably something that had to be added.

I forked your buildbot repository and added the patch in it. It it there:  http://github.com/even/buildbot/tree/master. Hope it is helping.

comment:11 Changed 4 years ago by marcusl

Ok. Looks good. I'm still waiting to hear from Brian on the clobber thing, but this is a good workaround.

I've updated folks on the mail-list, to see what the 'addFactoryArguments' is about, but beyond that, I don't think anything is holding this back. (If you'd like to join that discussion, you're welcome.)

Thanks for the nice work and the patches. :)

comment:12 Changed 4 years ago by even

As you saw, since I changed my mind and get the clobber as default behavior, testes are running smoothly now.

I would be happy to join the discussion since I would like to know what is that 'addFactoryArguments' thing to know if I have to update my patch to add my argument in it too. And for later changes as well maybe... The method is not documented and I totally miss its purpose...

comment:13 Changed 4 years ago by marcusl

Just pop in. The address is buildbot-devel@…. I use gmane.org to read it, but just subscribing is ok too.

comment:14 Changed 4 years ago by even

  • Keywords review added

I think review here is correct to.

comment:15 Changed 4 years ago by even

I fixed the call to addFactoryArguments in my branch based on Dustin explanation on the ML.

Now everything should be correct here.

comment:16 Changed 4 years ago by marcusl

  • Status changed from assigned to closed
  • Resolution set to fixed

Pushed to master.

See  b94b919dbeb25335affeb4ef32eb345574f4c20b and four earlier.

Note: See TracTickets for help on using tickets.