On 01/07/2011 02:03 PM, Gerry Reno wrote:
On 01/07/2011 12:04 PM, Gerry Reno wrote:
Heinz, Ok, but is this really going to work?
The various components that make up 'all' of x2go should be in their
own project.
So for example, x2goclient should be a separate project from x2goserver. This way each of them can have their own release version numbers. If you have the entire x2go under one project then the entire
project, clients, servers, all of it will have a new version number (tag) each time you release any new part of the codebase. DVCS operates on versioning the entire codebase and not on versioning separate files as was the case with CVS.
So if you have a stable server, 3.0.1-XX, but you have new clients
coming along and changing, the only way to prevent the server release from also incrementing is to have the clients and server separated into separate projects. And that way each would have their own release numbering scheme.
Regards, Gerry
Check here for an explanation of possible layouts:
http://stackoverflow.com/questions/2732020/git-repository-layout-for-server-...
Regards, Gerry
My preference would be the "One repo per project" layout. It's just simpler for people to understand and work with.
So 'x2go' application would consist of projects such as 'x2goclient', 'x2goserver', maybe 'x2gocommon'(if common is needed) each in its own git repository. And if you want to separate the clients then make projects like 'x2goclient-qt', 'x2goclient-gtk', etc.
So people would create a local 'x2go' work directory and then checkout all of the x2go projects underneath this 'x2go' directory:
$ mkdir x2go $ cd x2go $ git checkout git://git.berlios.de/x2goclient x2goclient $ git checkout git://git.berlios.de/x2goserver x2goserver
Regards, Gerry