Working with branches after 4.6

[Brian J. Tarricone]

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?
>>> Why?
>> 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.

-1

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.

	-b