Re: [Bf-committers] Migration to git and upgrade projects website

On 16 October 2013 10:15, Campbell Barton wrote: > IIRC it cut down the final repo size ~200mb (after aggressive GC on > both tests), some branches contain full checkouts of other projects > too - eg, > assimp, swig are in branches + docs & example files in some cases too. Ok, that's a decent sav

Re: [Bf-committers] Migration to git and upgrade projects website

On Wed, Oct 16, 2013 at 9:27 AM, Alex Fraser wrote: > On 16 October 2013 06:26, Campbell Barton wrote: >> At the moment we're looking to only convert branches that have been >> merged into trunk (so trunk has valid history). >> >> Other branches wont be lost and the subversion repository wont be

Re: [Bf-committers] Migration to git and upgrade projects website

On 16 October 2013 06:26, Campbell Barton wrote: > At the moment we're looking to only convert branches that have been > merged into trunk (so trunk has valid history). > > Other branches wont be lost and the subversion repository wont be > deleted, but there are so many branches which were never

Re: [Bf-committers] Migration to git and upgrade projects website

At the moment we're looking to only convert branches that have been merged into trunk (so trunk has valid history). Other branches wont be lost and the subversion repository wont be deleted, but there are so many branches which were never merged it adds a lot of overhead to making a full checkout

Re: [Bf-committers] Import based on extension

Nope, your not missing anything - this can be done, just needs someone to investigate a way to switch operators within the file-selector in a way which isn't going to cause problems later on (if done badly - it could really cause a mess IMHO). (eg, the file selector could store any number of opera

Re: [Bf-committers] Import based on extension

Unless I'm missing something, you could delay the loading of the mesh until you hit import, just as it is now. I would imagine this working as: - File > Import (opens file browser) - Select Object.obj (left bar shows obj-specific options such as Smooth Groups) - Select Object.dae (left bar shows

Re: [Bf-committers] Import based on extension

> > The main thing to resolve is how to show operator options (some way to > re-initialize different operator properties when selecting a file with > a different extension). Hmm, would this work? > class ImportByExtension(bpy.types.Operator, ImportHelper): > ... > def check(self, context)

Re: [Bf-committers] Migration to git and upgrade projects website

I use GiT for some personal stuff (with TortoiseGiT on Windows as GUI) and I love it so far. (For single dev-projects GiT doen't need a server to run the Repository). Will there be a 'bcon0' where the migration part happens? :) On 2013-10-15 12:24, Ton Roosendaal wrote: > Hi all, > > I had a m

Re: [Bf-committers] Import based on extension

I am unsure how practical this workflow would be; Import an object using the 'default' import settings. Then have in the toolshelf (on the left) the import options which a user can tweak. (changing an option will cause the current imported to be removed and re-import with the new settings.) Th

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Hi Gaia, What would the "Combine UV Layers" operator do exactly? How to solve conflicts in a predictable way when the same face has UV information in multiple layers. > this would allow old behavior which works very well in most cases (since i guess most objects only have one layer) For most of

Re: [Bf-committers] Migration to git and upgrade projects website

It's also easy to use your own clone on github/gitorious/etc. for independent coders who want their own code (or parts of it) separate from blender.org. Having an official git master of Blender will make it a lot easier to share commits between such independent branches, since you get the same vers

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

I understand that joining by index is not so good. And yes, i can rename the UV Layers before joining to avoid the problem. But honestly i believe this behavioral change of Blender is not completely implemented. I believe that adding a "Combine UV Layers" function is necessary to allow this change

Re: [Bf-committers] Migration to git and upgrade projects website

Very cool, Phabricator seems nice. I had never heard of it before. Jonathan Williamson http://cgcookie.com On Tue, Oct 15, 2013 at 9:24 AM, Brecht Van Lommel < brechtvanlom...@pandora.be> wrote: > Hi, > > I'm not sure what you mean by private git hosting, but we intend to > host the git reposit

Re: [Bf-committers] Migration to git and upgrade projects website

Hi, I'm not sure what you mean by private git hosting, but we intend to host the git repository ourselves, same as we do for svn now. We generally want to host our own code and trackers, and not depend on other companies for this. On the practical side, Github has the advantage that it is easier

Re: [Bf-committers] Migration to git and upgrade projects website

Yes, but you have to accept and live with the CGU… Some are not that "open", and they may change at any time! In a word, that would be dropping our freedom level. Those services are nice for individual/small orgs that cannot afford own servers, but if you can, always better to do it yourself. ;

Re: [Bf-committers] Migration to git and upgrade projects website

No, we don't look into hosting ;) We're setting up own git server in blender.org data center facilities and we will manage it. And for tracking/codereview we'll be using phabricator, which is much better comparing to hat other hosters could provide. More detailed information about what and when ex

Re: [Bf-committers] Migration to git and upgrade projects website

Github is also great to grow a bigger community :) On 10/15/13, Jonathan Williamson wrote: > Cheers! Sounds like you're looking at private GIT hosting? Any reason to > not simply use something like Github or Bitbucket? They include the full > tracker and make user management very easy. > > On Tue

Re: [Bf-committers] Migration to git and upgrade projects website

Cheers! Sounds like you're looking at private GIT hosting? Any reason to not simply use something like Github or Bitbucket? They include the full tracker and make user management very easy. On Tuesday, October 15, 2013, Luke Frisken wrote: > Will the branches be moved to git too? > > Luke > > > O

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [60737] trunk/blender: Interface / Template lists:

It seems the spacing was already off, more space below than above the filter and drag widget. Not because of this change, so you can ignore what I wrote. On Mon, Oct 14, 2013 at 7:21 PM, Thomas Dinges wrote: > Hi Brecht, > I just compard RC1 and SVN, the spacing is the same, the filter row and >

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

The reason why not is that the index of layers is not supposed to have any meaning, so there also should not be any option to join by index. The question should not be "why not" but "why", I still don't see a good argument to join by index? It's not because an option is simple to add or can be use

Re: [Bf-committers] Migration to git and upgrade projects website

Will the branches be moved to git too? Luke On Tue, Oct 15, 2013 at 9:24 PM, Ton Roosendaal wrote: > Hi all, > > I had a meeting here with Sergey and Brecht and they proposed to allocate > 2-3 weeks for them to do the svn-git migration and install a new tracker > and review system on our proje

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Here is proposed patch: http://www.pasteall.org/46507/diff On 15/10/2013 12:20, Bastien Montagne wrote: > Why not simply add a toggle to join cd layers either by name or by > indices (with first option by default)? I think it can be useful. And > we also use CustomData_merge in other contexts th

[Bf-committers] Migration to git and upgrade projects website

Hi all, I had a meeting here with Sergey and Brecht and they proposed to allocate 2-3 weeks for them to do the svn-git migration and install a new tracker and review system on our projects site. Such a migration of course would keep all code and tracker history. Projects site functionality sho

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Why not simply add a toggle to join cd layers either by name or by indices (with first option by default)? I think it can be useful. And we also use CustomData_merge in other contexts than join op, where we do not need name comparison. So as the change is pretty simple (will have a patch very s

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Why not rename the UV layer before joining, so that it matches? There's also vertex groups, shape keys, vertex colors, should all those have options to join by index too? I think it's better if they all just join by name instead of adding options here. If you choose a UV layer in a material that i

[Bf-committers] Pixar's Universal Scene Description

Maybe this can be of interest to someone... cheers, Thomas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Hi Gaia, Working on adding the option to the Join operator. But I really don’t think this would make it into 2.69, this is not strictly speaking a bug, and that kind of change would be more than risky to introduce at this point. Bastien On 15/10/2013 10:49, Gaia wrote: > Hi; > > For 2.69 when

[Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

Hi; For 2.69 when joining objects, then the UV maps are joined by name instead of by index. While this sounds like a good change unfortunately this results in an unpleasant follow up issue: Assume you have 2 objects, each with one single UV Layer, but both UV Layers are named differently. Now, af