U++ framework
Do not panic. Ask here before giving up.

Home » Community » Coffee corner » GIT
Re: GIT essentials [message #24377 is a reply to message #24373] Wed, 13 January 2010 09:47 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
concerning the GUI parts of git (with usability in mind when thinking of switching u++ project repo to git):

The Git GUI is quite usefull, supporting most of the command line features. a nice history few (one needs to get familiar with the view though, its due to different model than svn graph)

furthermore, there is TortoiseGIT for windows, which is in appearance relative to TortoiseSVN. it seems quite same in usage, though i havent tried it extensively.

concerning integration of git in TheIDE, just like SlikSVN, one can use the well defined command line operations in cygwin environment, though this is not trivial, i think.
GIT tryout [message #24387 is a reply to message #24373] Wed, 13 January 2010 14:47 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
for all who want to play around with git and u++:
in a post above, there was a link, but is not quite current anymore.

download and install git for windows i.e.
http://msysgit.googlecode.com/files/Git-1.6.5.1-preview20091 022.exe
when installing, choose with the radio buttons, to modify your PATH, should make no problems. and choose to commit lineendings as is.

then from git bash:

mkdir uppgit
cd uppgit
git svn clone -s http://upp-mirror.googlecode.com/svn .

takes around 4 hours to import the whole history.
total size 260 MB.

first time starting the GitGUI and opening the repo sinals 7000 loose objects, just allow to compress, and its gone, leaving you with a nice, clean clone of uppsvn.

normally, one can run

git svn fetch

or something like that, to keep in touch with svn repo, and
git svn rebase
to apply the changes (dont sure)

from git help:

"...After a repository is cloned, the fetch command will be able to update revisions without affecting the working tree; and the rebase command will be able to update the working tree with the latest changes. ..."

enjoy
Re: GIT tryout [message #24395 is a reply to message #24387] Wed, 13 January 2010 22:55 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Novo,

Quote:

This all is about workflows.

I personally trying to figure out which DVCS i need to use (and how to use it) in case of complicated code structure, many projects, many external projects, many versions of same code, plus U++, plus e.t.c.

All your suggestions are welcome. I appreciate your feedback.


Well in HG there there are lot's of extensions
http://mercurial.selenic.com/wiki/UsingExtensions#Extensions _Bundled_with_Mercurial

And in particular the Forest extension which allows to manage sub repositories inside a global repo: maybe this sounds a bit like what you need.
This plugin is still in beta state but it's very promising and it would fit very well to the Upp package organisation Or at least in bazaar

[Updated on: Wed, 13 January 2010 23:04]

Report message to a moderator

Re: GIT tryout [message #24396 is a reply to message #24387] Thu, 14 January 2010 01:52 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
kohait00 wrote on Wed, 13 January 2010 15:47

for all who want to play around with git and u++:
in a post above, there was a link, but is not quite current anymore.


If you're talking about http://gitorious.org/upp-mirror it wasn't updated since 6 December because when i've reinstalled the system i've lost my ssh key, now I have backup for it Smile and the repository will get updated every time I'm starting my laptop (that happen often). Also i've changed the user too, that's why is repo only 2 hours old. I think should be safe to use the repo from now on as I'm doing my graduation thesis with U++ and i'm using git for scm.

kohait00 wrote

takes around 4 hours to import the whole history.

I don't know what have you measured but it took me only half an hour to import whole history from upp-mirror Cool please don't scare new users Wink

Andrei
Re: GIT tryout [message #24400 is a reply to message #24396] Thu, 14 January 2010 12:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thank you for your efforts,

well, i started at 8 am and was done at 11:40 am or something, might have been due to slow connection also, or mi laptop is kinda slow, a lot of maybes, but it was that long, nice to hear it can go faster.

Re: GIT tryout [message #24437 is a reply to message #24395] Sun, 17 January 2010 20:25 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Didier wrote on Wed, 13 January 2010 16:55

Hi Novo,

Quote:

This all is about workflows.

I personally trying to figure out which DVCS i need to use (and how to use it) in case of complicated code structure, many projects, many external projects, many versions of same code, plus U++, plus e.t.c.

All your suggestions are welcome. I appreciate your feedback.


Well in HG there there are lot's of extensions
http://mercurial.selenic.com/wiki/UsingExtensions#Extensions _Bundled_with_Mercurial

And in particular the Forest extension which allows to manage sub repositories inside a global repo: maybe this sounds a bit like what you need.
This plugin is still in beta state but it's very promising and it would fit very well to the Upp package organisation Or at least in bazaar



Hi Didier,

Thanks for pointing out. It looks like Mercurial has a build in support for sub-projects since v 1.3.

I checked sub-project support in both Git and Mercurial. In both cases it seems to be somewhat confusing to me. There are many "don't do that" cases in both systems. Right now my preferences lean to Mercurial. I'll keep experimenting.

Below are links for those, who is looking for a new distributed VCS.

A Guide to Branching in Mercurial (pretty cool analysis, comments are also cool) - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me rcurial/

Git workflows:
http://osteele.com/archives/2008/05/my-git-workflow
http://osteele.com/archives/2008/05/commit-policies


Regards,
Novo
Re: GIT tryout [message #24442 is a reply to message #24437] Sun, 17 January 2010 23:37 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
With all this movement around DVCS in U++ forum, i think we have to start making our own DVCS, named Sit (Simple Information Tracker or Stay In Touch [with the code, of course]), sure it may not be wide used but anyway it's made by us for us, anyone for reviving UVS? Very Happy Just kidding.

Andrei
Re: GIT tryout [message #24447 is a reply to message #24442] Mon, 18 January 2010 01:21 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
andrei_natanael wrote on Sun, 17 January 2010 17:37

With all this movement around DVCS in U++ forum, i think we have to start making our own DVCS, named Sit (Simple Information Tracker or Stay In Touch [with the code, of course]), sure it may not be wide used but anyway it's made by us for us, anyone for reviving UVS? Very Happy Just kidding.

Andrei


Actually, I would try to reimplement monotone using U++. Database needs refactoring (text sha1 shouldn't be used within primary keys). Smile As a result of reimplementation size of a binary should shrink from 9M to 1.5M. Smile Unfortunately, this task doesn't have highest priority for me. For the next half a year I'm going to stick to the old-fashioned monotone.


Regards,
Novo
Re: GIT tryout [message #24557 is a reply to message #24447] Sun, 24 January 2010 12:53 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/
Re: GIT tryout [message #24578 is a reply to message #24557] Mon, 25 January 2010 05:32 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
andrei_natanael wrote on Sun, 24 January 2010 06:53

Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/


I like that:

"it is confusing ..."
"It will simply destroy the remote history ..."

And this is in an introduction for the beginners ...

Think several times before you start using this system. Smile


Regards,
Novo
Re: GIT tryout [message #24586 is a reply to message #24578] Mon, 25 January 2010 10:37 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Novo wrote on Mon, 25 January 2010 06:32

andrei_natanael wrote on Sun, 24 January 2010 06:53

Just new links about git, and yes, you should read this Smile
http://hades.name/blog/2010/01/17/git-your-friend-not-foe/
http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vo l-2-branches/


I like that:

"it is confusing ..."
"It will simply destroy the remote history ..."

And this is in an introduction for the beginners ...

Think several times before you start using this system. Smile


With a great power come a great responsibility. Right now the parts which i like at a DVCS are:

  • cloning speed
  • it's easy to create a branch and merge with another
  • new branch use the same place (i really like that because i'm not forced to create different assemblies in theide for different branches)


For me right now doesn't matter which DVCS but it have to have these features and probable more as i need them. I know that hg have better cross-platform implementation (because python) but i'm using git right now because it's supported better than others on some sites (gitorious, github) and there are many projects using it. I want a tool that doesn't stay in my way (frankly that happen with git sometimes).
Re: GIT [message #24587 is a reply to message #15990] Mon, 25 January 2010 10:45 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
I'm trying to get the grasp with GIT too, at least reading such articles, but I have difficult times as well.

I never hit any merge problems with SVN hard (thanks to my limited usage of it mostly, and little to my understanding how to do it in proper SVN way). My biggest problem with SVN is accidentally hitting commit with unfinished log message.

That said, the git does solve very little of my problems, as you can see. I think if I would join a more OSS project with more distributed decentralized development, I would hit limits of SVN much harder and welcome GIT.
And that's probably true for future of U++, I think in the long term (10+ years) it's inevitable to further loose the connection to mirek so the U++ would survive even without him later. If there will be still a point to have C++ framework at all. Very Happy But right now I feel very confused by GIT. I can see easily how Linus would be unable to work with SVN, but for the scale of project I work on, SVN fits it almost perfectly. :/

Yes, I'm sort of ranting I did expect bigger magic from GIT. And at the same time admitting it's superior. Looks like I'm crazy or momentarily confused too much.

But keep these things coming, I think at this rate I will try to use GIT in next months, after all it never hurts to learn something new, although in my case it keeps pushing the older things out of my head, so I have to choose wisely what set of technologies I do support at the same time. Smile
Re: GIT [message #24629 is a reply to message #24587] Mon, 25 January 2010 23:19 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi,

I started using DVCS's more than 10 years ago with RIP TEAMWARE, the Solaris (I think ) version for DVCS wich doesn't exist any more (Their build environment is not maintained any more Confused ).

Since then I used Clearcase/CVS/SVN and now HG.

The main concept about DVCS that you need to catch is the cloning part:
When you clone a project you don't only get a copy, you get a LINKED copy with local history, with which you can exchange history data (push/pull) and make merges if you want.

You can also exchange changesets (==history data) with any other clone, through http for example, as long as it has the same base history.
==> this allows you to give or receive from another developer selected changesets/branch or complete history update WITHOUT disturbing the main repository.
==> this gives a handy way for a distributed team to share changes before they are actually pushed to the main repository.
And when the changes are finalised, all that has to be done is to push them up to the main repository and there will be no conflicts !
This is the other great part about DVCS, all the conflicts are solved locally.

Of course with enhancements like in HG and GIT you can do exactly the same with local branches. But even then, these branches can also be exchanged with other clones.

My experience shows me that this is the only way that allows an easy management of complex merges between many developers where history can get very complex.

Once you have tasted DVCS and really learned to use it at its full power, you cannot come back no matter which DVCS you are using Cool !!!

Re: GIT [message #24632 is a reply to message #24629] Tue, 26 January 2010 04:08 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Didier wrote on Mon, 25 January 2010 17:19


Since then I used Clearcase/CVS/SVN and now HG.



In my case it is CVS/Clearcase/SVN/Perforce and now I'm using monotone at home. Smile

Quote:


Once you have tasted DVCS and really learned to use it at its full power, you cannot come back no matter which DVCS you are using Cool !!!



Imagine a project, which employs several hundreds developers, and VCS has several hundred thousands revisions. You will not be able to clone a repository in this case. Smile

Actually, I figured out how to switch to a different branch in monotone.

1) Check out a branch1:

mtn --db=database --branch=branch1 co .

2) Update to a branch branch2:

mtn --revision=h:branch2 update


So, now I know how to work with different branches using only one directory with three different DVCS: GIT, Mercurial, and Monotone. Smile


Regards,
Novo
Re: GIT [message #24647 is a reply to message #24632] Tue, 26 January 2010 11:33 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
Novo wrote on Tue, 26 January 2010 05:08


1) Check out a branch1:

mtn --db=database --branch=branch1 co .

2) Update to a branch branch2:

mtn --revision=h:branch2 update


That's something I personally dislike at monotone, it's showing you his internals. Using it you know you're using a VCS which use a database.
Another problem i have it's about generating RSA. mtn force you to have RSA key even if you're using it's repository locally. I really don't want a RSA key for my private repository, because i'm not sowing it to anyone over the network. I think it should be optionally.
If you'll follow monotone tutorial from http://www.monotone.ca/monotone.html you'll see how simple is to deal with it as a VCS Mad
I'm dreaming at the day when we will make usable software, the day when help manuals will disappear. Btw, i think bugs get into source becaus we don't know what we're doing and we don't know what other was doing.
Re: GIT [message #24702 is a reply to message #24647] Wed, 27 January 2010 20:12 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
andrei_natanael wrote on Tue, 26 January 2010 05:33

Novo wrote on Tue, 26 January 2010 05:08


1) Check out a branch1:

mtn --db=database --branch=branch1 co .

2) Update to a branch branch2:

mtn --revision=h:branch2 update


That's something I personally dislike at monotone, it's showing you his internals. Using it you know you're using a VCS which use a database.



You need to specify a database only once when you create a workspace. This nice feature lets you create multiple workspaces using only one repository/database. Smile

I personally find monotone much easier to use comparing to GIT and Mercurial. Though I miss good implementation of sub-modules.


Regards,
Novo
Re: GIT essentials [message #25289 is a reply to message #24373] Tue, 16 February 2010 14:35 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
[quote title=Novo wrote on Wed, 13 January 2010 06:40][quote title=andrei_natanael wrote on Tue, 12 January 2010 04:58]
Novo wrote on Tue, 12 January 2010 07:07


After a short research I chose "monotone".


2) I personally have ~30 packages in my MyApps. I do not want to checkout this mess all the time. I want to checkout a project and get only necessary packages. And when I update my project, I want these packages get updated. But in case when I use an external code, I do not want it to be updated all the time. I want to "rebase" it manually.



this is indeed a major issue with git. you cant say to one of your projects in your git repo "update to a certain revision", while leaving the rest of your packages beeing up to head revision i.e. thats because git is trating the entire base directory as content as mentionend by someone. you could check out earlier commits, but that would probably also change the state of the other packages, f they had been worked on meanwhile. in that case, svn is usefull actually..

i'm not that experienced in git to provide a workaround to this. probably the solution lies in an inteligent branching workflow. so one could checkout branch and rebase there some stuff needed from other packages or the like.

but since git is cheap, one could use a repo for each project as well. this is the apporach Xorg is doing, if you take a look inside the buildscript, the pull a bunch of repos, not just one.

i still believe, git is to be favored above others, since it's the most promising technology, not neccesarily because its the best, but because its a de facto standard in Open Source now and is pushed there. new promising technologies like u++ can profit A LOT, just by sticking to some stadard interfaces. the time of svn is running out.
Re: GIT essentials [message #25290 is a reply to message #25289] Tue, 16 February 2010 14:42 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?
Re: GIT essentials [message #25292 is a reply to message #25290] Tue, 16 February 2010 15:45 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
fudadmin wrote on Tue, 16 February 2010 15:42

could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?

I've used it only few times but if i remember correctly reasons were:
- not a wide used tool so every developers wanting to commit to U++ had to learn it and it wasn't released together with U++ or TheIDE, so one had to build it from uppbox folder... IIRC initially it was existing only on private repository
- compared to git, uvs isn't a DVCS
- i don't know if branching and merging was possible
- looked like U++ developer suffer from Not Invented Here syndrome and abandoning Uvs and choosing an external tool for SCM spread any rumors ( Very Happy no, it's not a reason, but we have our own IDE, our(STL) NTL, our own Image format [with hot-spots], site is made with U++ made tools)

Perhaps one should make a comparison between Uvs and SVN, GIT, BZR, etc. maybe we get back to it Wink

Andrei
Re: GIT essentials [message #25295 is a reply to message #25292] Tue, 16 February 2010 16:52 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
andrei_natanael wrote on Tue, 16 February 2010 14:45

fudadmin wrote on Tue, 16 February 2010 15:42

could anyone explain why Uvs2 was bad? And what features it was lacking comparing to git and/or other version c. systems?


- looked like U++ developer suffer from Not Invented Here syndrome and abandoning Uvs and choosing an external tool for SCM spread any rumors ( Very Happy no, it's not a reason, but we have our own IDE, our(STL) NTL, our own Image format [with hot-spots], site is made with U++ made tools)


Andrei


So, Linus can suffer from this sindrom, we not??? Shocked

[Updated on: Tue, 16 February 2010 16:53]

Report message to a moderator

Re: GIT essentials [message #25298 is a reply to message #25295] Tue, 16 February 2010 17:34 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
As I understand, Uvs2 is distributed.

Quote From wikipedia:

1. There may be many "central" repositories.
2. Code from disparate repositories are merged based on a web of trust, i.e., historical merit or quality of changes.
3. Lieutenants are project members who have the power to dynamically decide which branches to merge.
4. Network is not involved in most operations.
5. A separate set of "sync" operations are available for committing or receiving changes with remote repositories.

P.S. If a mankind hadn't made and/or used something better those who doesn't suffer from the syndrom would be still living on trees... Smile
Re: GIT essentials [message #25314 is a reply to message #25298] Tue, 16 February 2010 22:54 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
fudadmin wrote on Tue, 16 February 2010 18:34

As I understand, Uvs2 is distributed.

Quote From wikipedia:

1. There may be many "central" repositories.
2. Code from disparate repositories are merged based on a web of trust, i.e., historical merit or quality of changes.
3. Lieutenants are project members who have the power to dynamically decide which branches to merge.
4. Network is not involved in most operations.
5. A separate set of "sync" operations are available for committing or receiving changes with remote repositories.

P.S. If a mankind hadn't made and/or used something better those who doesn't suffer from the syndrom would be still living on trees... Smile

Sorry about NIH syndrome, maybe i made a bad joke Rolling Eyes
Another reason is that Uvs is GUI only so people who want to use CLI cannot use it.
However, i'll try Uvs again and maybe it may gain more love from me Wink . I have to check if all your points are applying to Uvs and maybe then we will forget about git waves... long live Uvs. Btw, last release is from last year (12/08/2009) so it's not so far. What about creating a poll "Uvs reloaded" Laughing ? That would drive Mirek crazy Evil or Very Mad . From Uvs to SVN and back.
Re: GIT essentials [message #25315 is a reply to message #25314] Tue, 16 February 2010 23:07 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
I found another reason while playing with Uvs. It's server dependent. One could not use it only locally without a ftp server. Hmm, i think i need a tutorial for Uvs. Smile
Re: GIT essentials [message #25317 is a reply to message #25315] Tue, 16 February 2010 23:57 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
Personally for me it's not too big problem to download and/or exchange code even via forums.
Re: GIT essentials [message #25337 is a reply to message #25317] Wed, 17 February 2010 16:14 Go to previous messageGo to next message
sergeynikitin is currently offline  sergeynikitin
Messages: 748
Registered: January 2008
Location: Moscow, Russia
Contributor

I want to say thank you to the topic, for what interested me using GIT. It was so convenient than other version control systems for personal development.

SergeyNikitin<U++>( linux, wine )
{
    under( Ubuntu || Debian || Raspbian );
}
Re: GIT essentials [message #28153 is a reply to message #25295] Thu, 19 August 2010 08:57 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Quote:


it's not a reason, but we have our own IDE, our(STL) NTL, our own Image format [with hot-spots], site is made with U++ made tools


think of google, they also have a whole bunch of things they offer, but some things they simply use from others (keep established standards) i.e. the googlecode svn repositories, only provide a mask for it, just as u++ does, or think of youtube / google video.

it's not only important to redesign and 'reinvent' things, but also to know what is worth keeping.

BTW: GIT
i'm using it for quite a while now, and can't without anymore Smile i enjoy the flexibility of branching merging and handling iin general. i still imagine mirek could profit from that more than from svn.
Re: GIT essentials [message #32605 is a reply to message #28153] Fri, 27 May 2011 14:45 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
to warm this one up a bit more:

the last git repository of upp somewhat died Smile
so i decided to make a new one.

https://gitorious.org/upp

now how to handle this best?

* setup a gitorious account for yourself, clone my repo in gitorious, just search for 'upp'. you will be able to commit to your clone, and send me merge requests, which so far does not make sense until it's based on svn. it'd breake history of svn, but for patch discussion it's quite nice

* for commiting to your repository, you will need to generate a ssh key pair 'ssh-keygen -t rsa' and paste the content of the pub file in the settings.

* based on your username, it will also be possible to define collaborators (those that can commit as well) to the upp original project, not only your clone.

cheers
Re: GIT essentials [message #32772 is a reply to message #32605] Tue, 07 June 2011 12:27 Go to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i think it would be great to make that git repository run on mireks server alongside google-mirror updater.
thats how that git could be refreshed hourly as well, and not like now every now and then (since i dont have a 24/7 running server sitting around)

i think it should be possible to even transfer ownership of that girorious repo to some more official mantainer Smile i could provide help with the scripts for that..

what do you think?

[Updated on: Tue, 07 June 2011 12:28]

Report message to a moderator

Previous Topic: Very nice icon set collection
Next Topic: Running Linux in a browser
Goto Forum:
  


Current Time: Sun Jun 07 10:54:42 GMT+2 2026

Total time taken to generate the page: 0.01440 seconds