Last Comment Bug 522445 - Adjust client.py for handling the creation of the 1.9.1 branch
: Adjust client.py for handling the creation of the 1.9.1 branch
Status: RESOLVED FIXED
: fixed-seamonkey2.0.1
Product: MailNews Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Thunderbird 3.0rc1
Assigned To: Mark Banner (:standard8)
:
Mentors:
Depends on:
Blocks: 522211
  Show dependency treegraph
 
Reported: 2009-10-15 02:21 PDT by Mark Banner (:standard8)
Modified: 2009-12-13 06:05 PST (History)
11 users (show)
standard8: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
WIP (3.86 KB, patch)
2009-10-21 14:33 PDT, Mark Banner (:standard8)
no flags Details | Diff | Splinter Review
The fix (8.47 KB, patch)
2009-10-22 02:09 PDT, Mark Banner (:standard8)
no flags Details | Diff | Splinter Review
The fix v2 (8.80 KB, patch)
2009-10-22 03:11 PDT, Mark Banner (:standard8)
kairo: review+
Details | Diff | Splinter Review
The fix v3 (8.94 KB, patch)
2009-10-22 06:00 PDT, Mark Banner (:standard8)
gozer: review+
Details | Diff | Splinter Review

Description Mark Banner (:standard8) 2009-10-15 02:21:08 PDT
This is the critical part of creating 1.9.1 branch. iirc we have previously discussed and semi-agreed the following:

- Existing pulls of comm-central should revert to comm-central + mozilla-central.
- To get the 1.9.1 branch you must pull the new comm-1.9.1 (when it is created) which will pull mozilla-1.9.1 by default.

Does this sound about right?

I think Justin (Callek) was working on this - I sent him a private email a couple of days ago, but not received a response yet, so one of us may need to pick this up if we are to get it done before Thursday 22nd.

gozer has also made the suggestion:

> client.py will just need to pick different defaults depending on which branch
> it's on. Just made me think of something, why not stick a top-level client.cfg
> or some such file where client.py gets it's defaults from (branch, revisions,
> etc) instead of in client.py itself. That way, should be easy to keep client.py
> 100% identical across branches, and isolate the changes to that single config
> file.

Which I think would probably be a good idea, though we may need to consider as a separate bug.
Comment 1 neil@parkwaycc.co.uk 2009-10-15 02:46:15 PDT
(In reply to comment #0)
> - Existing pulls of comm-central should revert to comm-central +
> mozilla-central.
Using the saved mozilla-central? Even then, it's still a big jump. And I assume that it wouldn't affect people not pulling directly from mozilla-1.9.1, right?

> - To get the 1.9.1 branch you must pull the new comm-1.9.1 (when it is created)
> which will pull mozilla-1.9.1 by default.
I suppose you have a window while the branch is still synchronised where you can tweak your .hgrc to migrate to comm-1.9.1?
Comment 2 Mark Banner (:standard8) 2009-10-15 02:58:01 PDT
(In reply to comment #1)
The other option is that we move:

* comm-central + mozilla-1.9.1 builds to become comm-1.9.1 + mozilla-1.9.1.
* comm-central + anything else builds to stay as they are.

Although I'm not sure if swapping from comm-central to comm-1.9.1 would be possible if you happen to have pulled more changesets than the branch point.

(In reply to comment #1)
> (In reply to comment #0)
> > - Existing pulls of comm-central should revert to comm-central +
> > mozilla-central.
> Using the saved mozilla-central? Even then, it's still a big jump. And I assume
> that it wouldn't affect people not pulling directly from mozilla-1.9.1, right?

Yes it is a big jump and it doesn't take into account 1.9.2 however I'm also starting to think that comm-central + mozilla-central should be the norm, and comm-central + mozilla-something else should be the exception.

Though that's probably something we need to think about going forward.
Comment 3 Robert Kaiser 2009-10-15 06:06:46 PDT
I don't think automagically switching comm-central to comm-1.9.1 as a base is sane or a good idea. And I don't think we need to care if people manually or automatically pulled in a mozilla-1.9.1 repo, we need to switch then to m-c as 1.9.1 will be soon desupported on comm-central.
Comment 4 Mark Banner (:standard8) 2009-10-21 03:59:50 PDT
I've not seen Justin around, so taking bug.
Comment 5 Mark Banner (:standard8) 2009-10-21 14:33:21 PDT
Created attachment 407614 [details] [diff] [review]
WIP

I think this patch should basically work. It follows the assumptions:

- If .treestate doesn't exist, either use the existing mozilla/ repo (if it exists) or clone from scratch (now mozilla-central).

- If .treestate exists and treestate => src_update_version is 2 do as if .treestate doesn't exist.

- If .treestate exists and treestate => src_update_version is 1 (which is the current version as comm-central stands today) then:

* If the source of the mozilla/ clone matches the regexp '(ssh|http|https):\/\/hg\.mozilla\.org\/releases/mozilla-1.9.1\/?$' then:
** move the mozilla/ repo to .mozilla-1.9.1
** clone a new mozilla/ repo from .mozilla-1.9.1 taking changesets up to GECKO_1_9_1_BASE
** set the new mozilla/ repo to clone from http://hg.mozilla.org/mozilla-central
** pull the rest of the changesets as part of the normal pull process.

This is all based on the existing tried and tested move_to_stable function.

I've a little bit more work to do, as I want to make some of the names more generic and do a little more testing - but I think this will do what we want it to.
Comment 6 Robert Kaiser 2009-10-21 14:43:32 PDT
what if .treestate exists, we might have a mozilla/ dir but we have no src_update_version (or something else than 1 or 2)?
Comment 7 Mark Banner (:standard8) 2009-10-21 14:58:47 PDT
(In reply to comment #6)
> what if .treestate exists, we might have a mozilla/ dir but we have no
> src_update_version (or something else than 1 or 2)?

If .treestate exists without src_update_version, then with the current patch we won't check & move the repo (presumably the developer created a .treestate with touch or something.

If .treestate exists with an "invalid" src_update_version, if it is less than 2 then we'll check & move, otherwise we won't do anything.
Comment 8 Robert Kaiser 2009-10-21 15:04:52 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > what if .treestate exists, we might have a mozilla/ dir but we have no
> > src_update_version (or something else than 1 or 2)?
> 
> If .treestate exists without src_update_version, then with the current patch we
> won't check & move the repo (presumably the developer created a .treestate with
> touch or something.

Hmm, I would have liked that to be treated the same as if it was an old version, but I'm OK as long as we have a clear solution and have thought about that case.
Comment 9 Mark Banner (:standard8) 2009-10-21 15:09:55 PDT
(In reply to comment #8)
> Hmm, I would have liked that to be treated the same as if it was an old
> version, but I'm OK as long as we have a clear solution and have thought about
> that case.

That's actually a good point and I agree now you mention it. I'll tweak the patch some more in the morning.
Comment 10 neil@parkwaycc.co.uk 2009-10-21 15:33:18 PDT
Comment on attachment 407614 [details] [diff] [review]
WIP

This could do with a few renames, e.g. MOZILLA_TRUNK_REPO_REGEXP to 
MOZILLA_STABLE_REPO_REGEXP and move_to_stable to move_to_trunk.

Why not try to reuse the old .mozilla-trunk folder?
Comment 11 Mark Banner (:standard8) 2009-10-21 15:36:31 PDT
(In reply to comment #10)
> (From update of attachment 407614 [details] [diff] [review])
> This could do with a few renames, e.g. MOZILLA_TRUNK_REPO_REGEXP to 
> MOZILLA_STABLE_REPO_REGEXP and move_to_stable to move_to_trunk.

Well I was thinking even more generic than that. The function works both ways (this is what I was saying I was going to do when I mentioned making names more generic in comment 5).

> Why not try to reuse the old .mozilla-trunk folder?

I'd forgotten about it.
Comment 12 Serge Gautherie (:sgautherie) 2009-10-21 22:21:33 PDT
Comment on attachment 407614 [details] [diff] [review]
WIP

>@@ -59,23 +67,31 @@ def repo_config():

>     move_to_stable() is also called.

Add 'conditionally' or 'as needed'!?

>     # 'src_update_version' values:
>     #   '1': "move_to_stable() was successfully run".

You may update/add_to/move this comment...

>@@ -84,6 +100,8 @@ def repo_config():
>+    sys.exit(0)
>+

I guess this is an extraneous local test change!?

>@@ -115,21 +133,21 @@ def move_to_stable():

Update
{
    Also switch checkout to MOZILLA_BASE_REV of Mozilla 1.9.1.
}
too.

In this version,
{
    # Do nothing if this function was already successfully run.
    # Shortcut: checking file existence is enough.
    if os.path.exists(TREE_STATE_FILE):
        return
}
should be removed too, as merged into repo_config().
As is, this check should be preventing this function from doing anything... ;-/
Comment 13 Mark Banner (:standard8) 2009-10-22 02:09:24 PDT
Created attachment 407734 [details] [diff] [review]
The fix

As I said, the previous one was very WIP and needed more changes. This one completes making it more generic and will probably go for review - I'm currently testing it to make sure it works correctly.
Comment 14 Mark Banner (:standard8) 2009-10-22 03:11:03 PDT
Created attachment 407737 [details] [diff] [review]
The fix v2

This fixes re-using .mozilla-trunk if it exists in the directory and corrects a couple of comments.
Comment 15 Serge Gautherie (:sgautherie) 2009-10-22 04:51:36 PDT
Comment on attachment 407737 [details] [diff] [review]
The fix v2

Some nits:

>+# '1' : mozilla/ may have been moved to mozilla-1.9.1 (or kept the same
>+#       depending on set up.

'setup'?! And missing ')'.

>+# '2' : mozilla/ may have been moved back to mozilla-central

Missing '.'.

>+# The old codename for the mozilla repository, e.g. "trunk" or "1.9.1". This
>+# will form the .mozilla-<codename> directory where the mozilla/ repo is 
>+# archived to.
>+SWITCH_MOZILLA_REPO_OLD_CODENAME = "1.9.1"

Why not make it |..._LOCATION = ".mozilla-" + "1.9.1"| directly?

>+# for the protocol type.

s/type/scheme/.

>+        # Do nothing if the current version is up to date.

This comment needs to be updated(/moved/...).

>+            sys.exit("Error: Renaming old backup directory failed!")

Add a warning that this step can be recovered manually only.
(The script will not run this code again.)
Comment 16 Robert Kaiser 2009-10-22 05:20:49 PDT
Comment on attachment 407737 [details] [diff] [review]
The fix v2

>     # Compile the Mozilla trunk regex.
>-    m_c_regex = re.compile(MOZILLA_TRUNK_REPO_REGEXP, re.I)
>+    m_c_regex = re.compile(SWITCH_MOZILLA_REPO_REGEXP, re.I)
>     match = m_c_regex.match(config.get('paths', 'default'))

nit: that isn't necessarily "Mozilla trunk" (comment) or "m-c" (var name) any more ;-)
(make it moz_old_regex instead?)

r=me with that (for what the patch actually does), but I'm somewhat weak at python code itself, so I'd like gozer or someone else with more python knowledge check if the code itself is OK.
Comment 17 Mark Banner (:standard8) 2009-10-22 05:56:54 PDT
(In reply to comment #15)
> (From update of attachment 407737 [details] [diff] [review])
> Some nits:
> 
> >+# '1' : mozilla/ may have been moved to mozilla-1.9.1 (or kept the same
> >+#       depending on set up.
> 
> 'setup'?! And missing ')'.

In British English (at least) 'setup' isn't a valid word. 'set up' and 'set-up' are the valid options.
Comment 18 Mark Banner (:standard8) 2009-10-22 06:00:21 PDT
Created attachment 407747 [details] [diff] [review]
The fix v3

Update patch.
Comment 19 Mark Banner (:standard8) 2009-10-22 08:09:25 PDT
Checked in: http://hg.mozilla.org/comm-central/rev/e6e6c30b8551

Note You need to log in before you can comment on or make changes to this bug.