Home AMX User Forum AMX Technical Discussion

VCS Workflow recomendations

Hi all,
i´m deciding wich version control system use, and by now i´m testing git and subversion+tortoise.
The matter is that we have a lot of AMX projects based on a "general" or "basic" code, wich is modified depending on each project requirements.
So, the "basic" code and each Project has its own version evolution. It´s obvious that when the basic code evolves, some projects may be affected and should be updated with the new code, but not all projects, it depends on the modules affected by the changes and the projects that use them.

Ok, now the question is how would you face the workflow in a VCS:
Would you make a main repository with all the projects (including the "basic" one) and then a branch for each one? Or would you make a repository for each Project with a linear workflow for each?
Any other idea will be appreciated

Thanks for the ideas!

Comments

  • I maintain separate repositories for each client, each containing all the projects for that client. I also maintain separate repositories for Duet and Netlinx module development. Find tagging more useful than branching in the client repositories with the reverse being true for the modules.
  • PhreaKPhreaK Posts: 966
    Everyones optimum workflow will be different however one that I've found works pretty well (with git) is to have one repository per module, one repository per reusable library and a repository for each project. When projects use a module or library this is brought in by a git submodule. Ditto for modules that use libraries, or libraries that have inter-dependancies.

    I tend to be a bit OCD about breaking code up into reusable components so don't have 'core' code template that I use. I instead each project tends to be a custom core that ties together the components required to create the desired system behaviour. That being said, if you've got a continuously evolving standard project you may get a bit of benefit from keeping this in a central repository's master branch, creating a new branch for each project then merging / rebasing things back onto the master that you want as part of the next evolution.
Sign In or Register to comment.