522296 - Changesets are shared across repos in life, make the model agree

Status: RESOLVED FIXED

(Mozilla Localizations :: Infrastructure, defect)

Description

[Axel Hecht [:Pike]]

Changesets in hg are shared across repositories if their hash is the same. For all practical matters, that is.

The model in life is disagreeing and we need to fix that.

This is in part reversing http://hg.mozilla.org/l10n/django-site/diff/3869081a6aef/life/models.py and the rest of that changeset, plus making the association between changesets and repos a ManyToMany, as not all changesets get pushed to repos. See branching.

I'm working on a patch, blocks 1.0 per conf call.

Comment 1

[Axel Hecht [:Pike]]

Attachment: remove some django commands we don't use anymore

This first patch is easy, just getting rid of some django commands that we don't really use anymore anyway. Removing them before trying to maintain them again.

Comment 2

[Axel Hecht [:Pike]]

Attachment: the actual patch

This is the actual patch.

The changes to life/models.py are rather drastic, as I had to change the order of the classes a bit.

With this patch, changesets exist independent of repos, somewhat. There's a many-to-many relation between the two. Pushes are hooked up to a single repo each, and there's a many-to-many between pushes and changesets, too.

This offers some interesting questions for the url values of changesets. I went for "let's use the url this changeset was pushed to first, and if never pushed, use the first repo this url is in, or just fake a urn:".

The only thing that I'm still a bit concerned about is how to associate parents to repos for repos that got branched upstream. I think it'd be fine to take the last parent of the currently pushed changesets that's not in the repo, and add all changesets from, well, say "any repo that pushed that changeset", and add those to the repo. But that's fishy still. Though it's hardly going to break unless you do upstream branches for just some in-repo branches, I guess. The worst thing is that if someone decides to push a patch that's not from a head, then the changesets to the old head won't show up in the db. But I'm fine with that.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 407031 [details] [diff] [review]
remove some django commands we don't use anymore

r+ this is easy

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 407033 [details] [diff] [review]
the actual patch

Sorry for a late review, I went through mercurial data model a bit before reviewing this ;)


>-    def save(self, force_insert=False, force_update=False):
>-        needsInitialChangeset = self.id is None
>-        # Call the "real" save() method.
>-        super(Repository, self).save(force_insert, force_update)
>-        if needsInitialChangeset:
>-            cs = Changeset(repository=self,
>-                           revision='0'*40)
>-            cs.save()
>-            cs.parents.add(cs)
>-            cs.save()
>-    def __unicode__(self):
>-        return self.name

You use the variable needsInitialChangeset only once.


>+class Repository(models.Model):
>+    """stores set of repositories
>+    
>+    Fields:
>+    name -- name of the repository
>+    url -- url to the repository
>+    changesets -- changesets inside this repository

I'm not sure if reponsitories should have a link to changesets. I rather think of changesets belonging to repositories. Do you have a strong opinion here?



>+    push_id = models.PositiveIntegerField(default=0)

push_id is specific per clone. I'm wondering if having it here won't become a kind of a trap. Everything in life.models is shared across clones of the same repository except of this field.


Beyond that, r+. Great stuff! I'm happy we're moving in this direction!

Comment 5

[Axel Hecht [:Pike]]

The direction of the relation between Changeset and Repository is mostly set by the fixtures. I have one common fixture which is the changeset 40*'0'. Now, all repo fixtures need to reference that one, so that's why the table is that way around. More metaphysically, changesets exist without repos, and then repos get them. Kinda. Metaphysically.

Regarding your comment on push_id, I don't get that. Pushes are per repo by definition. Take two empty upstream repos and one downstream repo with 3 changesets:
hg push -r 1 one
hg push one
hg push two

The pushes in one and two are totally different.

The push_id is actually the push_id in the upstream pushlog, too, so we don't have control over those values.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to comment #5)
> More metaphysically, changesets exist without repos, and then repos get
> them. Kinda. Metaphysically.

Yea, I think in the real life its the other way around, but that's a minor nit. If you feel like it makes it simpler for fixtures, I'm ok with this schema.

> Regarding your comment on push_id, I don't get that. Pushes are per repo by
> definition.

Yea, sorry, I realized that after pushing submit that I'm taking about changeset num, not push_id. Ignore pls.

Comment 7

[Axel Hecht [:Pike]]

With various commits to django-site and locale-inspector, I think we can mark this one FIXED.