Working with branches after 4.6
Brian J. Tarricone
bjt23 at cornell.edu
Fri Feb 20 22:06:52 CET 2009
Jannis Pohlmann wrote:
> On Thu, 19 Feb 2009 10:48:37 -0800
> "Brian J. Tarricone" <bjt23 at cornell.edu> wrote:
>> Nick Schermer wrote:
>>> Developers (!),
>>> Jannis had this nice point in his fosdem presentation that we should
>>> work more in branches, esp. for large (project wide) changes so
>>> trunk/master is not 'broken' for a long time and thus allowing us to
>>> do releases more often/easy because the main branch is always in
>>> good shape (the idea is good *wink*).
>> I dunno about you, but I never leave my trunk in a broken state ^_~.
>>> An important aspect of this is a vcs that does branching and merging
>>> nicely and I think we more or less agree git is the way to go.
>> Yeah pretty much. I was going to wait until 4.6.0 before bringing
>> all this up, but it seems some people are impatient, so... :-P
>>> I also heard rumours Brian wants a svn clone running along side?
>> This is just a nice-to-have for people who want to check out the
>> source tree using tools they're familiar with. It would be read-only
>> and hopefully require close to zero maintenance. Git is not exactly
>> user-friendly and has a rather steep learning curve.
>>> What to do with the goodies and archive?
>> If we're going to migrate to a new VCS, we're doing everything.
>> Maintaining the infrastructure for 2 different VCSs isn't something
>> I'm interested in doing.
>>> What are the permission problems/limitations?
>> Git doesn't do fine-grained inside-repo permissions by default. We'd
>> need to write (or find and modify) pre-commit hooks to (for example)
>> allow translator access to the po dirs but nothing else. This isn't
>> super hard, I don't think, but it's something we'd need to do. Bonus
>> points if it can use our existing svnperms.conf file for all the
>> permissions regexes. If not, someone needs to redo all that stuff.
> Hm. It should not be too hard, I guess one of us can do that. But I'm
> wondering if that's necessary. Basically, we could just allow one
> *real* user group to access all the repositories, including a few
> translations coordinators. And they could pull from the repositories of
> the translators and then push their changes to the repository. That's
> the nice thing about distributed version control.
That requires that all the translators be very familiar with git, and
have their own publicly-accessible repositories. That's a bit ridiculous.
> To make providing the translators' changes to the coordinators easier
> we could set up a separate repository web frontend, because clearly not
> everyone has the possibility to host his repository somewhere public.
Or that... but now that's just more work on site admin. Since these
days site admin is basically.... me... I veto this.
Though I *was* thinking about setting up a gitorious instance. Still,
this all puts much more burden on the translators than used to be the
case. Not very nice IMO.
More information about the Xfce4-dev