Closed Bug 522445 Opened 15 years ago Closed 15 years ago

Adjust client.py for handling the creation of the 1.9.1 branch

Categories

(MailNews Core :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0rc1

People

(Reporter: standard8, Assigned: standard8)

References

Details

(Keywords: fixed-seamonkey2.0.1)

Attachments

(1 file, 3 obsolete files)

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.
(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?
(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.
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.
I've not seen Justin around, so taking bug.
Assignee: nobody → bugzilla
Attached patch WIP (obsolete) — Splinter Review
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.
what if .treestate exists, we might have a mozilla/ dir but we have no src_update_version (or something else than 1 or 2)?
(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.
(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.
(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 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?
(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 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... ;-/
Attached patch The fix (obsolete) — Splinter Review
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.
Attachment #407614 - Attachment is obsolete: true
Attached patch The fix v2 (obsolete) — Splinter Review
This fixes re-using .mozilla-trunk if it exists in the directory and corrects a couple of comments.
Attachment #407734 - Attachment is obsolete: true
Attachment #407737 - Flags: review?(kairo)
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 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.
Attachment #407737 - Flags: review?(kairo)
Attachment #407737 - Flags: review?(gozer)
Attachment #407737 - Flags: review+
(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.
Attached patch The fix v3Splinter Review
Update patch.
Attachment #407737 - Attachment is obsolete: true
Attachment #407747 - Flags: review?(gozer)
Attachment #407737 - Flags: review?(gozer)
Attachment #407747 - Flags: review?(gozer) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/e6e6c30b8551
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0rc1
You need to log in before you can comment on or make changes to this bug.