[PATCH] [RFC] Using separate branch for l10n commits
Mikhail Gusarov
# User Mikhail Gusarov <dott...@dottedmag.net>
# Date 1250589153 -25200
# Node ID 3612c0939b24a481b424ceb2b2f32985487572e7
# Parent def8a42d6309d8da06f3111aba277a90df22a8a5
Use separate work branch for localizations (git backend)
diff -r def8a42d6309 -r 3612c0939b24 transifex/vcs/lib/support/git.py
--- a/transifex/vcs/lib/support/git.py Tue Aug 18 07:07:30 2009 +0700
+++ b/transifex/vcs/lib/support/git.py Tue Aug 18 16:52:33 2009 +0700
@@ -60,4 +60,5 @@
fetch = _git_factory('fetch')
push = _git_factory('push')
pull = _git_factory('pull')
+ rebase = _git_factory('rebase')
show_ref = _git_factory('show-ref')
diff -r def8a42d6309 -r 3612c0939b24 transifex/vcs/lib/types/git.py
--- a/transifex/vcs/lib/types/git.py Tue Aug 18 07:07:30 2009 +0700
+++ b/transifex/vcs/lib/types/git.py Tue Aug 18 16:52:33 2009 +0700
@@ -43,6 +43,7 @@
self.root = root
self.branch = branch
+ self.work_branch = branch + '-l10n'
self.path = os.path.normpath(os.path.join(REPO_PATH, name))
self.path = os.path.abspath(self.path)
@@ -79,6 +80,9 @@
repo.branch(self.branch, remote_branch)
repo.checkout(self.branch)
+
+ repo.branch('-f', self.work_branch)
+ repo.checkout(self.work_branch)
return repo
@@ -122,7 +126,10 @@
"""
revspec = 'origin/%s' % self.branch
self.repo.fetch('origin')
+ self.repo.checkout(self.branch)
self.repo.reset(revspec, hard=True)
+ self.repo.checkout(self.work_branch)
+ self.repo.rebase(self.branch)
@need_repo
def get_rev(self, obj=None):
@@ -160,5 +167,4 @@
self.repo.commit(m=msg.encode('utf-8'),
author=user.encode('utf-8'))
- self.repo.push('origin', self.branch)
-
+ self.repo.push('-f', 'origin', self.work_branch)
Mikhail Gusarov
Twas brillig at 11:00:27 18.08.2009 UTC+00 when dott...@dottedmag.net
did gyre and gimble:
MG> Use separate work branch for localizations (git backend)
This is RFC, and not a real patch - needs much more work to be applied,
but I think the idea is clear: make a separate branch, commit to it and
rebase it when master branch updates.
Dimitris Glezos
One of the biggest challenges when we lose sync with HEAD is how
rebase/merge conflicts will be handled. Say, if someone commits
something on master and another person changes the same file on the
l10n branch. The issue is that Tx does everything non-interactively,
so the rebase should always be smooth.
Additionally, after a rebase, how are the new changesets going to
appear upstream after a push -f?
-d
--
Dimitris Glezos
Transifex: The Multilingual Publishing Revolution
http://www.transifex.net/ -- http://www.indifex.com/
Mikhail Gusarov
Twas brillig at 13:17:43 19.08.2009 UTC+03 when dimi...@glezos.com did gyre and gimble:
DG> One of the biggest challenges when we lose sync with HEAD is how
DG> rebase/merge conflicts will be handled. Say, if someone commits
DG> something on master and another person changes the same file on the
DG> l10n branch.
The only way to have the conflict here is to change .po file in master
branch in a way that introduces the conflict, as -l10n branch is created
From the current master state.
This problem is not unique to the separate l10n branch: there is
possibility to have conflict even with committing to the same branch due
to race condition:
- Tx fetches the source
- upstream pushes something to repository
- Tx commits the changed .po
- Tx pushes the update, and fails due to non-forward push.
We just need a rule of resolving conflicts. Like 'upstream is always
right', or 'we are always right'. That's just a question of adding
--strategy=ours or --strategy=theirs to git-rebase call.
In worst case .po update will be delayed to the next time someone
changes the translation.
DG> Additionally, after a rebase, how are the new changesets going to
DG> appear upstream after a push -f?
Upstream developer will do the merge - that's the point. The idea of
separate branch is to have something in between the automatic commit to
master and e-mailing changes: as usable as commit to master and as
non-disruptive as e-mailing changes.
Dimitris Glezos
>
> Twas brillig at 13:17:43 19.08.2009 UTC+03 when dimi...@glezos.com did gyre and gimble:
>
> DG> One of the biggest challenges when we lose sync with HEAD is how
> DG> rebase/merge conflicts will be handled. Say, if someone commits
> DG> something on master and another person changes the same file on the
> DG> l10n branch.
>
> The only way to have the conflict here is to change .po file in master
> branch in a way that introduces the conflict, as -l10n branch is created
> From the current master state.
>
> This problem is not unique to the separate l10n branch: there is
> possibility to have conflict even with committing to the same branch due
> to race condition:
>
> - Tx fetches the source
> - upstream pushes something to repository
> - Tx commits the changed .po
> - Tx pushes the update, and fails due to non-forward push.
>
> We just need a rule of resolving conflicts. Like 'upstream is always
> right', or 'we are always right'. That's just a question of adding
> --strategy=ours or --strategy=theirs to git-rebase call.
Right. At this point we're mitigating this risk by fetching right
before the commit.
I guess the safest way, to avoid losing data, is --strategy=ours,
since 'their' commit is already in history.
> In worst case .po update will be delayed to the next time someone
> changes the translation.
>
> DG> Additionally, after a rebase, how are the new changesets going to
> DG> appear upstream after a push -f?
>
> Upstream developer will do the merge - that's the point. The idea of
> separate branch is to have something in between the automatic commit to
> master and e-mailing changes: as usable as commit to master and as
> non-disruptive as e-mailing changes.
Agreed. The problem is that translation file merges are hard because
nobody speaks all the languages in the files.
I guess it'd help a lot to have a flow diagram with the different
states and possible scenarios, to catch any conflict scenarios and
decide what to do when they appear (notification? automatic rebase?).
In general, we're trying to treat all VCSs the same and avoid doing
too much VCS work & abstractions.