The structure of projects and version control.

[macmanpb]

Ok, for now i thought a project is like an folder in which i can place subfolders to organize it.

For example. I have a project that is my company and in it there are my customer-folders and in that folders with there different designs organized. Today i wake up! The version control is for one project and not for a single folder or design in that project. Puh, have you an idea how we should handle hundreds of projects on a first level? 

How can i organize that? Any ideas?

In my example that means, the version controlling affects each design in each customer subfolder.

If i make a branch each changes of other customer designs will be logged and have to merged into the master when the branch is closed.

Ok, this depends on how the concept of projects is.

[schneik-adsk]

I can share my personal view on this...

Think of grouping projects based on data that shares calendar timelines, designers and engineers. One way is to look at the products you make and consider the groups of data that me up a product:

• CAD Assemblies
• CAD Parts
• CAD Drawings
• Renderings
• Instructions
• Specifications
• Engineering calculations
• Office files
• And more!

Branches are of projects and all data in the project, not just an assemblies. This would mean in large projects the Milestones and project history will be very convoluted, and branches will easily be confused across the many products. In this situation the project has become overloaded.

For example a team that has many products in a few projects will find that the branches and milestones are harder to manage.

Each product could have its own milestones and branches. As these are collected at the project, the collected list of branches across all products will be overwhelming.

A better structure would be to separate products into projects. It might make sense for a family of products to share a project. Remember the rule would be to group data that shares milestones, team members and other assets.

If you have a product family where you have multiple products that are related and share parts, then you might consider grouping these products into one project.

What to do:

Reorganize projects before diving in on Branches.

• Organize projects around products. This ensures the project branches make sense.
• Multiple related products are OK, unrelated products in the same project could cause unneeded confusion.
• Create sub folders and organize data into cleaner hierarchies of products.
• Create new projects and move product hierarchies out to these new projects.
• Move these projects to your team Hub.

For Teams forming up, move projects out of personal hubs into their team hub. Set the team hub as the default hub.

The big limitation today is cross project references, but let's hope that ability arrives soon then we will have everything we need to break up projects into better organized hierarchies that map more to a product.