Ken Robinson's picture

So I am knee deep wading around in my first TKLDev. I started my own GIT repo to keep track of it. 

I was wondering, should I have one repo with multi-branches supporting all kinds of versions or should have a different repo for each version. 

Example, RT has a 4.0 and 4.2 release. Also I may build a packaged version using wheezy packages of request tracker (RT 4.0.7) and one using the up stream (4.0.22). Should have have two master branches for each release 4.0/4.2 one for up stream the other for packages, or should I have one for each. 4.0-package 4.0-upstream and a 4.2-package (does not exist yet) and a 4.2-upstream?

I like the idea of having everything under one roof but that could get crazy branching. But all issues and such in one cozy place. I also like the idea of each one has their own repo, nice and neat everything in it's own place. My gut is with the multi-repos


Remeber this is for TKLDev build code

Jeremy Davis's picture

Having them as branches would allow you to quickly and easily share much of the code. But overall, my inclination would be to make them separate repos altogether. Just for the fact that you will never be merging the branches and there will be some parts that will need to be quite different and that might get a bit messy...

Just my 2c though...

Ken Robinson's picture

I thought two repos would be best as well.


Also, I have decided to go the package route for 4.0 for now, just to get the app out there an running with out too much fuss. If there is a need (for me or some one else) I may create a 4.2 and start from upstream until they get packages. 

Did my first package build tonight and will test install it via ISO and play around see whats what. 


The TKLDev tool kit is awesome. Learning a lot!



Jeremy Davis's picture

Nice! :)

Add new comment