Dear X2go-folks,
the X2go Git repository at BerliOS has been set up today. You can
browse the X2go-Git at BerliOS:
http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=master
http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=develop
The master branch is the project's release branch. A commit to master
will be equivalent to an X2go release. The develop branch will be the
branch that you can derive your own branches from for features you
want to implement (and possibly propose for integration into X2go).
Currently, the develop branch is a simple copy of the master branch.
Heinz and Alex have just finished a complete rewrite of the x2goclient
that will use libssh as opposed to ssh binary calls in the background.
Alex has proposed a patch to upstream libssh that got accepted and
once the new libssh version is released there will be a commit to the
develop branch containing the latest x2goclient code. This is expected
for the end of January 2011.
We are also still discussing the Git branching model details. As a
template for the discussion we use this document (as proposed by
HedgeHog from the x2go-dev list):
http://nvie.com/posts/a-successful-git-branching-model/
There will be some slight modifications to this model but the
discussion will take place along this very fine piece of work.
You can anonymously clone a working copy of X2go Git with this command:
$ git clone git://git.berlios.de/x2go x2go
BerliOS users should also be able to clone a working copy with this command:
$ git clone ssh://<developername>@git.berlios.de/gitroot/x2go x2go
If you want to branch off of the develop branch for your own
implementation work, then do this after having cloned the BerliOS Git:
$ cd x2go $ git checkout develop $ git checkout -b branch_<featurename>
... where <featurename> is a short string of your choice (at least for
now) that describes the feature you are going to implement.
If you intend working on a feature that you would like to become part
of X2go some time in the future then we should agree on some, e.g.:
For now, feature branches will stay on your local file systems. Once,
we have finished our discussion on the Git branching model we will
inform you on how merge requests can be send to the project (probably
via a commit of your feature branch to BerliOS, but we will see...).
Looking forward to a growing project and an active X2go community with
lots of fine contributions...
light+love, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Nice work Mike!
I just tried a clone using bzr's 'bzr-git' plugin and it worked.
$ bzr branch git://git.berlios.de/x2go x2go Branched 6 revision(s).
$ find . -maxdepth 2 -type d ! -ipath "./.*" . ./lib ./lib/nxcompshad ./lib/nxcompext ./lib/nxcomp ./client ./client/x2goclient-cli ./client/nxproxy ./client/x2goclient ./client/pinentry-x2go ./server ./server/cups-x2go ./server/x2goserver ./server/_kde_ ./server/_ldap_ ./server/_lxde_ ./server/_gnome_ ./server/x2goprint ./server/x2goserver-one ./server/x2goagent ./server/x2godesktopsharing ./server/x2gospyglass ./contrib ./contrib/windows ./tce ./tce/x2gousbmount ./tce/x2gothinclientsystem ./tce/x2gosmartcardrules ./tce/x2gocdmanager ./tce/x2gothinclient
Looks like it pulled it ok.
So it looks like I can work with the repo in bzr.
Regards, Gerry
On 01/06/2011 08:24 PM, Gerry Reno wrote:
Nice work Mike!
I just tried a clone using bzr's 'bzr-git' plugin and it worked.
$ bzr branch git://git.berlios.de/x2go x2go Branched 6 revision(s).
$ find . -maxdepth 2 -type d ! -ipath "./.*" . ./lib ./lib/nxcompshad ./lib/nxcompext ./lib/nxcomp ./client ./client/x2goclient-cli ./client/nxproxy ./client/x2goclient ./client/pinentry-x2go ./server ./server/cups-x2go ./server/x2goserver ./server/_kde_ ./server/_ldap_ ./server/_lxde_ ./server/_gnome_ ./server/x2goprint ./server/x2goserver-one ./server/x2goagent ./server/x2godesktopsharing ./server/x2gospyglass ./contrib ./contrib/windows ./tce ./tce/x2gousbmount ./tce/x2gothinclientsystem ./tce/x2gosmartcardrules ./tce/x2gocdmanager ./tce/x2gothinclient
Looks like it pulled it ok.
So it looks like I can work with the repo in bzr.
Regards, Gerry
Log looks right as well:
revno: 6 git commit: 1512f523a749251c09065da91f1865db30f89435 committer: Mike Gabriel <m.gabriel@das-netzwerkteam.de> timestamp: Thu 2011-01-06 13:41:42 +0100 message:
revno: 3 git commit: 9e9fb0007f40af26c1c98a8473531635100431ec committer: Mike Gabriel <m.gabriel@das-netzwerkteam.de> timestamp: Sun 2011-01-02 17:22:50 +0100 message:
revno: 2 git commit: 80ca69563c3a3aeab9740410dcc7dcbd05a00ee9 committer: Mike Gabriel <m.gabriel@das-netzwerkteam.de> timestamp: Sun 2011-01-02 17:19:55 +0100 message:
Use --include-merges or -n0 to see merged revisions.
Regards, Gerry
The only problem I see is that there is no commit history other than just the repo creation activity:
$ bzr tags $
No tagged releases. :-(
So it is not possible to recreate existing releases.
Regards, Gerry
Hi Gerry,
On Fr 07 Jan 2011 03:05:18 CET Gerry Reno wrote:
The only problem I see is that there is no commit history other than just the repo creation activity:
$ bzr tags $
No tagged releases. :-(
So it is not possible to recreate existing releases.
Regards, Gerry
Yes, indeed. The release will be tagged on the master branch only,
anyway. So you are fine with the develop branch already.
I'll discuss the missing tag and its name/version with Heinz and Alex.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Gerry,
On Fr 07 Jan 2011 03:05:18 CET Gerry Reno wrote:
The only problem I see is that there is no commit history other than just the repo creation activity:
$ bzr tags $
No tagged releases. :-(
So it is not possible to recreate existing releases.
Regards, Gerry
please update your working copy. There should now be a tag named
,,uthoern'' (Uthörn).
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 01/07/2011 04:27 AM, Mike Gabriel wrote:
Hi Gerry,
On Fr 07 Jan 2011 03:05:18 CET Gerry Reno wrote:
The only problem I see is that there is no commit history other than just the repo creation activity:
$ bzr tags $
No tagged releases. :-(
So it is not possible to recreate existing releases.
Regards, Gerry
please update your working copy. There should now be a tag named ,,uthoern'' (Uthörn).
Greets, Mike
$ bzr pull Using saved parent location: git://git.berlios.de/x2go No revisions to pull.
$ bzr tags uthoern 6 $
Mike, yes it pulled a tag. But what is the definition of this 'uthoern' tag? A tag usually corresponds to a released version of software and so the tag usually contains the release number, something like 3.0.1-14 etc. How does uthoern corresponds to a x2go release?
Regards, Gerry
Hello Gerry,
Awas am 07.01.2011 16:41, schrieb Gerry Reno:
$ bzr pull Using saved parent location: git://git.berlios.de/x2go No revisions to pull.
$ bzr tags uthoern 6 $
Mike, yes it pulled a tag. But what is the definition of this 'uthoern' tag? A tag usually corresponds to a released version of software and so the tag usually contains the release number, something like 3.0.1-14 etc. How does uthoern corresponds to a x2go release?
Uthoern is our actual release by name, not by number. As there are a lot of Packages with different version counters you can use with this release, it was an idea of me and mike to use the "release name" instead of the "version number".
Regards,
Heinz
On 01/07/2011 11:48 AM, Heinz-M. Graesing wrote:
Hello Gerry,
Awas am 07.01.2011 16:41, schrieb Gerry Reno:
$ bzr pull Using saved parent location: git://git.berlios.de/x2go No revisions to pull.
$ bzr tags uthoern 6 $
Mike, yes it pulled a tag. But what is the definition of this 'uthoern' tag? A tag usually corresponds to a released version of software and so the tag usually contains the release number, something like 3.0.1-14 etc. How does uthoern corresponds to a x2go release?
Uthoern is our actual release by name, not by number. As there are a lot of Packages with different version counters you can use with this release, it was an idea of me and mike to use the "release name" instead of the "version number".
Regards,
Heinz
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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
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
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
Hi Heinz,
I don't like that Idea. For someone doing a lot of development, that might be fine. But For someone new, it's always nice to see which is the newest version.
Cheers
Morty
Am 07.01.2011 17:48, Heinz-M. Graesing schrieb:
Uthoern is our actual release by name, not by number. As there are a lot of Packages with different version counters you can use with this release, it was an idea of me and mike to use the "release name" instead of the "version number".
hello,
i just browse and in the server part i don't see x2goserver-home, is any reason for that?
may be a stange question: can i use it to make a repository on my machine and so not to go to internet to install x2go?
michel
On 01/06/2011 11:50 PM, Mike Gabriel wrote:
Dear X2go-folks,
the X2go Git repository at BerliOS has been set up today. You can browse the X2go-Git at BerliOS: http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=master http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=develop
META INFORMATION
The master branch is the project's release branch. A commit to master will be equivalent to an X2go release. The develop branch will be the branch that you can derive your own branches from for features you want to implement (and possibly propose for integration into X2go).
Currently, the develop branch is a simple copy of the master branch. Heinz and Alex have just finished a complete rewrite of the x2goclient that will use libssh as opposed to ssh binary calls in the background. Alex has proposed a patch to upstream libssh that got accepted and once the new libssh version is released there will be a commit to the develop branch containing the latest x2goclient code. This is expected for the end of January 2011.
We are also still discussing the Git branching model details. As a template for the discussion we use this document (as proposed by HedgeHog from the x2go-dev list): http://nvie.com/posts/a-successful-git-branching-model/
There will be some slight modifications to this model but the discussion will take place along this very fine piece of work.
USING X2go/Git:
You can anonymously clone a working copy of X2go Git with this command:
$ git clone git://git.berlios.de/x2go x2go
BerliOS users should also be able to clone a working copy with this command:
$ git clone ssh://<developername>@git.berlios.de/gitroot/x2go x2go
If you want to branch off of the develop branch for your own implementation work, then do this after having cloned the BerliOS Git:
$ cd x2go $ git checkout develop $ git checkout -b branch_<featurename>
... where <featurename> is a short string of your choice (at least for now) that describes the feature you are going to implement.
If you intend working on a feature that you would like to become part of X2go some time in the future then we should agree on some, e.g.:
- please talk to Heinz and Alex about your ideas first, don't simply start working
- make sure that you work in small portions, do not rewrite the complete code and expect a merge
- document your work
- ... ??? ...
For now, feature branches will stay on your local file systems. Once, we have finished our discussion on the Git branching model we will inform you on how merge requests can be send to the project (probably via a commit of your feature branch to BerliOS, but we will see...).
Looking forward to a growing project and an active X2go community with lots of fine contributions...
light+love, Mike
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-- kamerun@immerda.ch homepage: http://sokolo.cronopios.org linux friends sokolo new road limbe / cameroun phone : (00237) 743 514 33
On Fr 07 Jan 2011 11:29:58 CET "kamerun@immerda.ch" wrote:
hello,
i just browse and in the server part i don't see x2goserver-home, is
any reason for that?
Yes, you are right...
@Heinz+Alex: ping!!!
may be a stange question: can i use it to make a repository on my
machine and so not to go to internet to install x2go?michel
for purposes of installation the Git is not appropriate.
Please use a tool like apt-mirror (apt-get install apt-mirror) to
mirror the X2go package archive:
stable/uthoern: deb http://x2go.obviously-nice.de/deb lenny main
testing/pre-baikal: deb http://x2go.obviously-nice.de/deb heuler main
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Am 07.01.2011 13:35, schrieb Mike Gabriel:
On Fr 07 Jan 2011 11:29:58 CET "kamerun@immerda.ch" wrote:
hello,
i just browse and in the server part i don't see x2goserver-home, is any reason for that?
Yes, you are right...
@Heinz+Alex: ping!!!
Hello Michel,
x2goserver-home is a installation variation of x2goserver, not a different piece of software. x2goserver-home is a deb metapackage which helps you to install x2goserver. So there is no difference of the "application" x2goserver-home and x2goserver. You can have a look at the tar.gz that is used for package building to see what is done by the debian package:
http://x2go.obviously-nice.de/deb/pool-lenny/x2goserver-one/x2goserver-one_3...
Regards,
Heinz
Mike Gabriel schreef:
Dear X2go-folks,
the X2go Git repository at BerliOS has been set up today. You can browse the X2go-Git at BerliOS: http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=master http://git.berlios.de/cgi-bin/cgit.cgi/x2go/tree/?h=develop
Great, this is a big step forwards ;-)
With regards, Paul van der Vlis.