Home → Suggestions →

Per-project Repository Groups

• Edit

zach.burlingame

Mar 17, 2014 @ 11:11 PM

Presently, the project is the basic - and only - unit by which repositories can be grouped. All repositories under a given project are in a flat model. This can get rather cluttered when you have a bunch of people working on a project and maintaining development, QA, and stable lines. In our development workflow, for each project we have dev, qa, and stable master repos. Then we utilize per-user repos on the centralized repo server to facilitate code sharing and code reviews before items are moved into the master.

Presently with our current product (FogCreek's Kiln ForYourServer) we have this which works very well for us:

 projectX/  
     dev/  
         master  
         userA  
         userB
         ...
         MajorFeatureBranch1
     qa/
         master
         userA
         userB
     stable/
          master
          userA
          userB
 projectY   
     dev/
         master
         userA
         userB
     qa/
         master
         userA
         userB
     stable/
          master
          userA
          userB

The URLs that result from this are hierarchical for both the project (level1) and the group (level2). Also, the various web pages allow you to focus your attention on repositories within a group.

With HgLab's single level hierarchy, we end up with something like this which gets rather clumsy:

 projectX/  
     dev_master  
     dev_userA  
     dev_userB
     ....
     dev_MajorFeatureBranch1
     qa_master
     qa_userA
     qa_userB
     stable_master
     stable_userA
     stable_userB
 projectY/
     dev_master
     dev_userA
     dev_userB
     qa_master
     qa_userA
     qa_userB
     stable_master
     stable_userA
     stable_userB

1. Support Staff 1 Posted by Anton Gogolev on Mar 18, 2014 @ 12:20 PM

   

   Zach,

   I was pondering over an idea of adding repository groups, but I couldn't fit them into the overall picture.

   Is there any chance this can be solved by personal forks of repositories? This will effectively "invert" your suggested option, making each user a "group" of its own:

   projectX/
     dev
     qa
     stable
     userA/
       dev
       stable
     userB/
       qa
     ....
   

   Each user will have a chance to fork a repository within a project and then issue a Merge Request back to the mainline repository.

   • Edit

2. 2 Posted by zach.burlingame on Mar 20, 2014 @ 12:33 AM

   

   Thanks for the prompt reply Anton!

   I think that layout would work in general. I'll have to mull this one over to see how it impacts our workflow, especially with regard to how our code reviews and merges go.

   • Edit

3. Anton Gogolev closed this discussion on Jun 28, 2014 @ 01:08 PM.