You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(6) |
Jul
(9) |
Aug
(16) |
Sep
(17) |
Oct
(50) |
Nov
(12) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(42) |
Feb
(1) |
Mar
(27) |
Apr
(20) |
May
(3) |
Jun
(4) |
Jul
(3) |
Aug
(6) |
Sep
(7) |
Oct
(22) |
Nov
(8) |
Dec
|
2005 |
Jan
(22) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(18) |
Jul
|
Aug
(66) |
Sep
(46) |
Oct
(58) |
Nov
(11) |
Dec
(7) |
2006 |
Jan
|
Feb
(2) |
Mar
(16) |
Apr
(21) |
May
(23) |
Jun
(8) |
Jul
(18) |
Aug
(72) |
Sep
(98) |
Oct
(65) |
Nov
(26) |
Dec
(38) |
2007 |
Jan
(31) |
Feb
(45) |
Mar
(62) |
Apr
(19) |
May
(21) |
Jun
(37) |
Jul
(24) |
Aug
(14) |
Sep
(29) |
Oct
(32) |
Nov
(15) |
Dec
(9) |
2008 |
Jan
(11) |
Feb
(14) |
Mar
(27) |
Apr
(5) |
May
(29) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(5) |
Oct
|
Nov
(27) |
Dec
(20) |
2009 |
Jan
(51) |
Feb
(94) |
Mar
(40) |
Apr
(3) |
May
(11) |
Jun
(34) |
Jul
(23) |
Aug
(11) |
Sep
(3) |
Oct
(10) |
Nov
(2) |
Dec
(8) |
2010 |
Jan
(16) |
Feb
(13) |
Mar
(5) |
Apr
(16) |
May
(3) |
Jun
|
Jul
|
Aug
(17) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(18) |
Feb
(31) |
Mar
(2) |
Apr
(6) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
From: Marcus L. <ma...@ya...> - 2011-05-02 09:17:08
|
Carsten Neumann skrev 2011-04-08 21:42: > Hello Dirk, > > On 04/08/2011 10:22 AM, Dirk Reiners wrote: >> Just as a thought experiment, what would it take to have a web application that >> could connect to an OpenSG program on a server and receive RemoteAspect syncs >> through HTTP? Would that be something interesting to try? > > i'm probably missing something because of lack of understanding how web > applications in a browser work, but to do something useful with > RemoteAspects syncs on the client side you'd need to have an OpenSG > scene graph where you apply them. Doesn't that require either a JS > implementation of OpenSG or at least JS bindings? You need something that parse the RemoteAspect into something a javascript library/client can handle, yes. That could be an OpenSG-implementation in JS, or something more lightweight provided that the Server (C++) does some processing with the RemoteAspect data to make it more suitable for the web-client JS-lib to work with. Intriguing concept. And since WebGL is (mostly?) GL ES 2.0, there aren't _that_ many core/buffer/object types to manage, compared to what OpenSG offers. > Bindings probably have the issue that you'd still need the user to > execute native code that back the bindings, so a plugin would be required? Yup. /Marcus |
From: Carsten N. <car...@gm...> - 2011-04-15 21:56:37
|
Hello Gerrit, On 04/14/2011 09:54 PM, Gerrit Voß wrote: > On Apr 15, 2011, at 7:18, Carsten Neumann<car...@gm...> wrote: >> >> sorry about the breakage. Most of the changes i understand, but this one in the ogre loader: argh, i actually meant to ask how i can reproduce these to avoid the problem in the future, do i need to build with CMAKE_BUILD_TYPE=DebugGV or so? Cheers, Carsten |
From: Gerrit V. <vo...@vo...> - 2011-04-15 02:53:49
|
Hi, On Apr 15, 2011, at 7:18, Carsten Neumann <car...@gm...> wrote: > Hello Gerrit, > > On 04/14/2011 03:02 AM, Gerrit Voss wrote: >> - Log ----------------------------------------------------------------- >> commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=6eb7a447866343c04e924cbea983cf2995c82590 >> commit 6eb7a447866343c04e924cbea983cf2995c82590 >> Author: gerrit<ger...@vo...> >> Date: Thu Apr 14 16:00:24 2011 +0800 >> >> fixed: minor compile problems > > sorry about the breakage. Most of the changes i understand, but this one in the ogre loader: > > OgreSkeletonReader::readAnimationLink(void) > { > std::string skelName = readString(_is); > - Real32 scale = readReal32(_is); > +#ifndef OSG_OGRE_SILENT > + Real32 scale = > +#endif > + readReal32(_is); > > is this to avoid an unused variable warning? Why does it not affect skelName which is also only used in the log message? my guess because string is not a pod, so the compiler can't be sure of sideeffects, for pods like float he can ;) > Can we use osgSinkUnusedWarning (from OSGConecptPropertyChecks.h) instead [1], I find that more readable than using CPP to kill half lines ;) fine with me, wasn't aware of it ;) will use it in the future ;) kind regards gerrit |
From: Carsten N. <car...@gm...> - 2011-04-14 23:18:51
|
Hello Gerrit, On 04/14/2011 03:02 AM, Gerrit Voss wrote: > - Log ----------------------------------------------------------------- > commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=6eb7a447866343c04e924cbea983cf2995c82590 > commit 6eb7a447866343c04e924cbea983cf2995c82590 > Author: gerrit<ger...@vo...> > Date: Thu Apr 14 16:00:24 2011 +0800 > > fixed: minor compile problems sorry about the breakage. Most of the changes i understand, but this one in the ogre loader: OgreSkeletonReader::readAnimationLink(void) { std::string skelName = readString(_is); - Real32 scale = readReal32(_is); +#ifndef OSG_OGRE_SILENT + Real32 scale = +#endif + readReal32(_is); is this to avoid an unused variable warning? Why does it not affect skelName which is also only used in the log message? Can we use osgSinkUnusedWarning (from OSGConecptPropertyChecks.h) instead [1], I find that more readable than using CPP to kill half lines ;) Cheers, Carsten [1] see attached |
From: Carsten N. <car...@gm...> - 2011-04-08 19:42:32
|
Hello Dirk, On 04/08/2011 10:22 AM, Dirk Reiners wrote: > Just as a thought experiment, what would it take to have a web application that > could connect to an OpenSG program on a server and receive RemoteAspect syncs > through HTTP? Would that be something interesting to try? i'm probably missing something because of lack of understanding how web applications in a browser work, but to do something useful with RemoteAspects syncs on the client side you'd need to have an OpenSG scene graph where you apply them. Doesn't that require either a JS implementation of OpenSG or at least JS bindings? Bindings probably have the issue that you'd still need the user to execute native code that back the bindings, so a plugin would be required? Cheers, Carsten |
From: Dirk R. <dir...@gm...> - 2011-04-08 15:22:21
|
Hi All, on the OSG list there is some discussion about embedding OSG ina web page, and this just came through: Message: 2 Date: Thu, 07 Apr 2011 15:27:54 -0400 From: Peter Amstutz <pet...@ts...> To: OpenSceneGraph Users <osg...@li...> Subject: Re: [osg-users] OSG plugin for browsers Message-ID: <4D9...@ts...> Content-Type: text/plain; charset=ISO-8859-1 On 4/7/2011 5:30 AM, Thibault Genessay wrote: > > Other people have thought of alternatives to display 3D content: > > - osgjs - which re-implements the OSG in Javascript. Although the API > > is very close to the C++ one, it is not a way to embed an OSG app in a > > browser > > - webGL. If I am not mistaken, this leaves out the OSG entirely, and > > only aims at displaying 3D models. Kind of a new VRML thing. > > Just to clarify, WebGL consists of Javascript bindings for OpenGL, which are used by osgjs for rendering. So if you already have a C++ program, you would need to port it to javascript in order to use such libraries. Possibly you could emit opengl calls from the C++ server side and execute them in the client with WebGL, but that would be pretty bandwidth intensive and subject to lag. Broadly speaking, if the goal is to execute native code using OSG in the browser, you're going to run up against all the security, hardware architecture etc problems that plague all such efforts. My preference would be for a solution that transmits the scene graph to the browser to be rendered using something like osgjs and the server sends scene graph updates, but that is somewhat complex and difficult to do transparently as osg lacks the necessary "value changed" hooks to record the changes that occur in the scene graph from frame to frame. ... but OpenSG has them. :) Just as a thought experiment, what would it take to have a web application that could connect to an OpenSG program on a server and receive RemoteAspect syncs through HTTP? Would that be something interesting to try? I'm not advocating working on it just yet, but somehow the idea is intriguing... What do you think? Dirk |
From: Carsten N. <car...@gm...> - 2011-04-04 18:03:44
|
Hello Gerrit, On 03/28/2011 04:27 AM, Gerrit Voss wrote: > - Log ----------------------------------------------------------------- > commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=65ad7349c4fe28912f483798536a38842213deab > commit 65ad7349c4fe28912f483798536a38842213deab > Author: Gerrit Voss<ge...@te...> > Date: Mon Mar 28 17:24:37 2011 +0800 > > fixed: vrml inline reading > : allow to switch of file not found warning so app can handle it (sfh) > : add wrz for gzip wrl files to be handled by vrml loader virtual NodeTransitPtr read(const Char8 *fileName, + bool bWarnNotFound = true, GraphOpSeq *graphOpSeq = _defaultgraphOpSeq, Resolver resolver = NULL); I'm moving the new parameter to the end. Since pointer auto convert to boolean this silently converts a GraphOpSeq* to bool and does not run any GraphOps ;( I.e. this: SceneFileHandler::the()->read(fileName.c_str(), myGraphOps); compiles, but does not do what it used to do... Cheers, Carsten |
From: Gerrit V. <vo...@vo...> - 2011-03-15 04:15:05
|
Hi, I will be there so if anybody wants to talk about OpenSG, where it is going, where problems are, what we should change, what we should fix, what we did wrong, what we should address, ... Just drop me a line ;) kind regards gerrit -- Gerrit Voß 盖瑞客 --------------------------------------------------- Fraunhofer IDM @ NTU 南洋理工大学, Nanyang Technological University, (NTU) 新加坡, Singapore -------------------------------------------------- If we communicate everything we ever think, speech just becomes static. And all of us become bores. J. Clarkson |
From: Carsten N. <car...@gm...> - 2011-03-03 16:53:28
|
Hello all, just as an FYI I've set up a post-receive hook for the git repo on sourceforge to sent commit mails, the script is the one recommended by sf here: <https://sourceforge.net/apps/trac/sourceforge/wiki/Git#Commitemailhooksetup> and lives in /home/scm_git/o/op/opensg/opensg/hooks when using a sf shell - in case you feel like tuning it or there are problems and you need to disable it (just remove the post-receive symlink to the actual script). Cheers, Carsten |
From: Dirk R. <dir...@gm...> - 2011-02-26 16:15:06
|
Hi Gerrit, On 02/25/2011 07:21 PM, Gerrit Voß wrote: >>> as I saw the repo is there I will push OpenSG 2 to >>> >>> opensg.git.sourceforge.net/gitroot/opensg/opensg >>> >>> or are there any objections ? >> >> sounds good to me. Go for it. > > done ;) Looks good. I will turn off the svn on Tuesday, so if anybody still needs to do anything with it, please do it now. Yours Dirk |
From: Gerrit V. <vo...@vo...> - 2011-02-26 01:21:50
|
Hi, On Fri, 2011-02-25 at 18:35 -0600, Dirk Reiners wrote: > Hi Gerrit, > > On 02/25/2011 06:25 PM, Gerrit Voß wrote: > > > > as I saw the repo is there I will push OpenSG 2 to > > > > opensg.git.sourceforge.net/gitroot/opensg/opensg > > > > or are there any objections ? > > sounds good to me. Go for it. done ;) kind regards gerrit |
From: Gerrit V. <vo...@vo...> - 2011-02-26 00:47:14
|
Dear all, as the sf cvs is back (with log mails ;)) I pushed the github commits back to sf so both repositories are identical again. If nobody wants me to keep him around I will remove the github tree and go back to let the cvs repository be the master. As I don't know how many people have adjusted their build scripts I'll leave the tree until early next week. kind regards gerrit -- Gerrit Voß 盖瑞客 --------------------------------------------------- Fraunhofer IDM @ NTU 南洋理工大学, Nanyang Technological University, (NTU) 新加坡, Singapore -------------------------------------------------- If we communicate everything we ever think, speech just becomes static. And all of us become bores. J. Clarkson |
From: Dirk R. <dir...@gm...> - 2011-02-26 00:35:42
|
Hi Gerrit, On 02/25/2011 06:25 PM, Gerrit Voß wrote: > > as I saw the repo is there I will push OpenSG 2 to > > opensg.git.sourceforge.net/gitroot/opensg/opensg > > or are there any objections ? sounds good to me. Go for it. Dirk |
From: Gerrit V. <vo...@vo...> - 2011-02-26 00:26:04
|
Hi, On Fri, 2011-02-25 at 15:10 +0800, Gerrit Voß wrote: > Hi, > > Am Feb 25, 2011 um 1:40 PM schrieb Dirk Reiners <dir...@gm...>: > > > > The question now is do we want to use the default repo > > (opensg.git.sourceforge.net/gitroot/opensg/opensg) or the OpenSG 2 repo > > (opensg.git.sourceforge.net/gitroot/opensg/opensg_2)? > > > > I would prefer the default, as that is the one that is listed on the SF code > > access page. The page also says that there might be other repos, but I'm > > sceptical about people reading that... If 1 should move to git I would probably > > create an opensg_1 repo > > agree, so lets go with gitroot/opensg/opensg this way we can push 2 to opensg_2 > if we live to see the day that works starts on 3 ;) as I saw the repo is there I will push OpenSG 2 to opensg.git.sourceforge.net/gitroot/opensg/opensg or are there any objections ? kind regards gerrit |
From: Gerrit V. <vo...@vo...> - 2011-02-25 07:05:09
|
Hi, Am Feb 25, 2011 um 1:40 PM schrieb Dirk Reiners <dir...@gm...>: > > Hi Gerrit, > > On 02/24/2011 11:25 PM, Gerrit Voß wrote: >> >> From what I read it seems a temporary problem that affects all scms right >> now, some scripts/modules missing. > > So we'll ignore it for now. yep, sounds like a plan ;) >> The annoying part was that it had to be done locally and not as with >> svn through server based properties. > > OK, that is a little annoying. Can we put a pre-commit script to fix or at least > check this? I haven't tried yet. >> or at least stick to such classics as emacs vs vi ;) > > Nedit! :) not antique enough and requiring a window toolkit clearly disqualifies it from entering the fray ;) And it does not pass the minimum finger dexterity threshold required to weed out the weak ;) >> I'm ready to go, so as soon as the repo is created (I'm not in the admin list so >> I can't right now) on sf I can push the complete thing (except branches, do we still need >> them ?). But these can move over later if needed with no problems. > > You're not an admin? Oops, that was not on purpose. You are now. s*** there goes my excuse ;) > Branches: Don't think we need them any more, honestly. > >> I actually would like to do it asap as I want to cleanout the sandbox and than start merging >> toolbox changes back to the main tree. With git i can keep the correct comitter and >> don't have to change the commit messages to attribute things correctly, little >> less work ;) > > I had some minor changes that I just submitted. saw them ;) > The question now is do we want to use the default repo > (opensg.git.sourceforge.net/gitroot/opensg/opensg) or the OpenSG 2 repo > (opensg.git.sourceforge.net/gitroot/opensg/opensg_2)? > > I would prefer the default, as that is the one that is listed on the SF code > access page. The page also says that there might be other repos, but I'm > sceptical about people reading that... If 1 should move to git I would probably > create an opensg_1 repo agree, so lets go with gitroot/opensg/opensg this way we can push 2 to opensg_2 if we live to see the day that works starts on 3 ;) bis denn gerrit |
From: Dirk R. <dir...@gm...> - 2011-02-25 05:40:25
|
Hi Gerrit, On 02/24/2011 11:25 PM, Gerrit Voß wrote: > > From what I read it seems a temporary problem that affects all scms right > now, some scripts/modules missing. So we'll ignore it for now. > The annoying part was that it had to be done locally and not as with > svn through server based properties. OK, that is a little annoying. Can we put a pre-commit script to fix or at least check this? > or at least stick to such classics as emacs vs vi ;) Nedit! :) > I'm ready to go, so as soon as the repo is created (I'm not in the admin list so > I can't right now) on sf I can push the complete thing (except branches, do we still need > them ?). But these can move over later if needed with no problems. You're not an admin? Oops, that was not on purpose. You are now. Branches: Don't think we need them any more, honestly. > I actually would like to do it asap as I want to cleanout the sandbox and than start merging > toolbox changes back to the main tree. With git i can keep the correct comitter and > don't have to change the commit messages to attribute things correctly, little > less work ;) I had some minor changes that I just submitted. The question now is do we want to use the default repo (opensg.git.sourceforge.net/gitroot/opensg/opensg) or the OpenSG 2 repo (opensg.git.sourceforge.net/gitroot/opensg/opensg_2)? I would prefer the default, as that is the one that is listed on the SF code access page. The page also says that there might be other repos, but I'm sceptical about people reading that... If 1 should move to git I would probably create an opensg_1 repo for that. Yours Dirk |
From: Gerrit V. <vo...@vo...> - 2011-02-25 05:21:15
|
Hi, Am Feb 25, 2011 um 12:48 PM schrieb Dirk Reiners <dir...@gm...>: > > Hi Gerrit, > > On 02/24/2011 06:33 PM, Gerrit Voß wrote: >> >> It should not, if the cvs on sf is back and will work for a while >> (does anybody know for how long) > > From what I can tell there are no plans to stop supporting CVS. They recommend > not using it for new stuff, but I can't see an end-of-life date for CVS. > > The one thing that's not working right now is email from the SCM servers, but > that's true for git, too. Not sure if that's a general problems or just not done > yet. From what I read it seems a temporary problem that affects all scms right now, some scripts/modules missing. >> I do not see the need to keep the git >> mirror around for longer, so I will push the changes back to sf and >> remove it. And if it is back for good, do we really want to move 1.x to >> a different scm. At least I would like to avoid having 1 and 2 as >> different branches in the same repository if there is no technical >> element that forces us to do so. > > I would not have them as branches. SF supports mutliple repos, so we can have > separate repos for 1 and 2. Permissions can only be set for all, so we'll have > to depend on people being resonable, but I don't see giving a lot of people > write access to the repo, especially with git. Ah ok, missed that one. > >> I still use cygwin so no experience with 'native' window tools. We had >> some students use it and the only thing I encountered was to force it >> to respect and keep the newlines, but there is a config switch >> for .git/config somewhere. > > That should be manageable. The annoying part was that it had to be done locally and not as with svn through server based properties. >> IMHO we don't have to open the 'which dvcs' discussion, at least not >> starting from the 'oh look there are others' level. If there is >> a compelling technical reason to look into this fine, but otherwise I >> would stick with git. > > Agreed, let's keep the holy wars on topic (i.e. scenegraphs). ;) or at least stick to such classics as emacs vs vi ;) >> Workflow is a different story. As said I prefer a linear stable >> history so I prefer to rebase/cherry-pick my branches back to head and >> commit them from there as linear continuations. Merging with the detours >> staying visible is not my taste (yet) > > All for it. Github for the mess, SF for the clean, linear history where nobody > ever commits buggy code. ;) > > When do you want to move? I'm ready to go, so as soon as the repo is created (I'm not in the admin list so I can't right now) on sf I can push the complete thing (except branches, do we still need them ?). But these can move over later if needed with no problems. I actually would like to do it asap as I want to cleanout the sandbox and than start merging toolbox changes back to the main tree. With git i can keep the correct comitter and don't have to change the commit messages to attribute things correctly, little less work ;) bis denn gerrit |
From: Dirk R. <dir...@gm...> - 2011-02-25 04:48:55
|
Hi Gerrit, On 02/24/2011 06:33 PM, Gerrit Voß wrote: > > It should not, if the cvs on sf is back and will work for a while > (does anybody know for how long) From what I can tell there are no plans to stop supporting CVS. They recommend not using it for new stuff, but I can't see an end-of-life date for CVS. The one thing that's not working right now is email from the SCM servers, but that's true for git, too. Not sure if that's a general problems or just not done yet. > I do not see the need to keep the git > mirror around for longer, so I will push the changes back to sf and > remove it. And if it is back for good, do we really want to move 1.x to > a different scm. At least I would like to avoid having 1 and 2 as > different branches in the same repository if there is no technical > element that forces us to do so. I would not have them as branches. SF supports mutliple repos, so we can have separate repos for 1 and 2. Permissions can only be set for all, so we'll have to depend on people being resonable, but I don't see giving a lot of people write access to the repo, especially with git. The real decision is for the folks that will be focused on using and managing 1... Do you guys want CVS or git? > I still use cygwin so no experience with 'native' window tools. We had > some students use it and the only thing I encountered was to force it > to respect and keep the newlines, but there is a config switch > for .git/config somewhere. That should be manageable. > IMHO we don't have to open the 'which dvcs' discussion, at least not > starting from the 'oh look there are others' level. If there is > a compelling technical reason to look into this fine, but otherwise I > would stick with git. Agreed, let's keep the holy wars on topic (i.e. scenegraphs). ;) > Workflow is a different story. As said I prefer a linear stable > history so I prefer to rebase/cherry-pick my branches back to head and > commit them from there as linear continuations. Merging with the detours > staying visible is not my taste (yet) All for it. Github for the mess, SF for the clean, linear history where nobody ever commits buggy code. ;) When do you want to move? Dirk |
From: Gerrit V. <vo...@vo...> - 2011-02-25 00:34:16
|
Hi, On Thu, 2011-02-24 at 13:43 -0600, Carsten Neumann wrote: > Hello all, > > On 02/24/2011 09:57 AM, Dirk Reiners wrote: > > On 02/24/2011 05:18 AM, Timm Drevensek wrote: > >> So the CVS& GIT content is currently diverging by the begin of February. > > > > Yes. The git was just a snapshot to give access while SF cleans up their mess, > > there is no live link between CVS and git. > > locally I have the same patches in my CVS checkout, I can commit them > (split to mirror the git commits of course) - just wanted to make sure > there is no smarter way to do this than "by hand" (which is not a big > deal for the 7 patches in this case). It should not, if the cvs on sf is back and will work for a while (does anybody know for how long) I do not see the need to keep the git mirror around for longer, so I will push the changes back to sf and remove it. And if it is back for good, do we really want to move 1.x to a different scm. At least I would like to avoid having 1 and 2 as different branches in the same repository if there is no technical element that forces us to do so. > >> We > >> don't have any experience with git so far but it would be a good point to > >> start with dcvs's, since there are tools like smartgit or tortoisegit for windows. > > > > Yup. And I would be very interested in experiences anybody has with git on Windows. > > I've only used it a tiny bit, worked fine for that. It does give you > bash on windows (from mingw) which by itself justifies the installation ;) I still use cygwin so no experience with 'native' window tools. We had some students use it and the only thing I encountered was to force it to respect and keep the newlines, but there is a config switch for .git/config somewhere. > >> I goggled around and found out, that there are many possibility's with git > >> like mirroring of svn etc. > >> (http://blog.tfnico.com/2010/11/git-svn-mirror-for-multiple-branches.html) > >> There is also Mercurial (HG) with Bitbucket and ongoing comparisations like > >> "Git is Wesley Snipes, Mercurial is Denzel Washington and SVN is Morgan > >> Freeman" It sounds more like a religious war between HG& GIT...but it seems > >> to be, that git offers more features?! > > > > There is a religious war out, but I don't think it concerns us much. For the > > things we do IMHO either one would be fine. > > agreed. Perhaps the only relevant factor is that the popularity of git > (in terms of # projects/developers using it) seems to be far greater > than for any other dvcs, there should be good support for it in the long > run and if the next great idea for vcs hits there is going to be a > git2XYZ tool to do the conversion ;) > > > The main difference I can see is > > that hg keeps the history sacred while git allows you change it to keep it > > clean. Given that I'm expecting to use SF as an official git with tightly > > controlled write access I don't think we will have to mess with the history a > > whole lot, development will not be done on that tree, so I don't see a problem > > here. The main advantage is that there people on the team that have experience > > with git. IMHO we don't have to open the 'which dvcs' discussion, at least not starting from the 'oh look there are others' level. If there is a compelling technical reason to look into this fine, but otherwise I would stick with git. Workflow is a different story. As said I prefer a linear stable history so I prefer to rebase/cherry-pick my branches back to head and commit them from there as linear continuations. Merging with the detours staying visible is not my taste (yet) kind regards gerrit |
From: Carsten N. <car...@gm...> - 2011-02-24 19:43:51
|
Hello all, On 02/24/2011 09:57 AM, Dirk Reiners wrote: > On 02/24/2011 05:18 AM, Timm Drevensek wrote: >> So the CVS& GIT content is currently diverging by the begin of February. > > Yes. The git was just a snapshot to give access while SF cleans up their mess, > there is no live link between CVS and git. locally I have the same patches in my CVS checkout, I can commit them (split to mirror the git commits of course) - just wanted to make sure there is no smarter way to do this than "by hand" (which is not a big deal for the 7 patches in this case). >> We >> don't have any experience with git so far but it would be a good point to >> start with dcvs's, since there are tools like smartgit or tortoisegit for windows. > > Yup. And I would be very interested in experiences anybody has with git on Windows. I've only used it a tiny bit, worked fine for that. It does give you bash on windows (from mingw) which by itself justifies the installation ;) >> I goggled around and found out, that there are many possibility's with git >> like mirroring of svn etc. >> (http://blog.tfnico.com/2010/11/git-svn-mirror-for-multiple-branches.html) >> There is also Mercurial (HG) with Bitbucket and ongoing comparisations like >> "Git is Wesley Snipes, Mercurial is Denzel Washington and SVN is Morgan >> Freeman" It sounds more like a religious war between HG& GIT...but it seems >> to be, that git offers more features?! > > There is a religious war out, but I don't think it concerns us much. For the > things we do IMHO either one would be fine. agreed. Perhaps the only relevant factor is that the popularity of git (in terms of # projects/developers using it) seems to be far greater than for any other dvcs, there should be good support for it in the long run and if the next great idea for vcs hits there is going to be a git2XYZ tool to do the conversion ;) > The main difference I can see is > that hg keeps the history sacred while git allows you change it to keep it > clean. Given that I'm expecting to use SF as an official git with tightly > controlled write access I don't think we will have to mess with the history a > whole lot, development will not be done on that tree, so I don't see a problem > here. The main advantage is that there people on the team that have experience > with git. Cheers, Carsten |
From: Dirk R. <dir...@gm...> - 2011-02-24 15:56:30
|
Hi Timm, On 02/24/2011 05:18 AM, Timm Drevensek wrote: > So the CVS& GIT content is currently diverging by the begin of February. Yes. The git was just a snapshot to give access while SF cleans up their mess, there is no live link between CVS and git. > As far as I see the situation in Darmstadt, we have no ongoing plans for > switching to OpenSG 2.x in the near future...but someday we will switch. > So far for us, a stable OpenSG 1.x source solution is currently important. Understood. That's why i see you guys more as the keepers of 1 than Gerrit, Carsten or me (you're the ones fixing all the bugs in 1 lately anyway ;). > We > don't have any experience with git so far but it would be a good point to > start with dcvs's, since there are tools like smartgit or tortoisegit for windows. Yup. And I would be very interested in experiences anybody has with git on Windows. > I goggled around and found out, that there are many possibility's with git > like mirroring of svn etc. > (http://blog.tfnico.com/2010/11/git-svn-mirror-for-multiple-branches.html) > There is also Mercurial (HG) with Bitbucket and ongoing comparisations like > "Git is Wesley Snipes, Mercurial is Denzel Washington and SVN is Morgan > Freeman" It sounds more like a religious war between HG& GIT...but it seems > to be, that git offers more features?! There is a religious war out, but I don't think it concerns us much. For the things we do IMHO either one would be fine. The main difference I can see is that hg keeps the history sacred while git allows you change it to keep it clean. Given that I'm expecting to use SF as an official git with tightly controlled write access I don't think we will have to mess with the history a whole lot, development will not be done on that tree, so I don't see a problem here. The main advantage is that there people on the team that have experience with git. Dirk |
From: Timm D. <Tim...@ig...> - 2011-02-24 11:19:03
|
> > hmm, while I like git for my local work I still would prefer a central > > repository that ensures a linear history where the history can not be > > changed easily. I still run this combination locally for repositories where groups of people can commit to. > > given that you're the one with the most GIT experience (well, definitely more than me) I'll defer to your judgment. So the CVS & GIT content is currently diverging by the begin of February. > > I feel that one has to change the workflow when transitioning to git > > and adapt to the multi-repository model with a very limited set of > > comitters for a single repository and pulls between repositories or patches per mail as the norm. > > I'm all for it. That's what I was thinking for SF with you, me and Carsten for > OpenSG2 and Johannes, Patrick and somebody else from Darmstadt for 1. As far as I see the situation in Darmstadt, we have no ongoing plans for switching to OpenSG 2.x in the near future...but someday we will switch. So far for us, a stable OpenSG 1.x source solution is currently important. We don't have any experience with git so far but it would be a good point to start with dcvs's, since there are tools like smartgit or tortoisegit for windows. > > Just replacing svn by git and go on like before does not seem to be the best approach to me. > > IMHO we need to put in a little more thinking about how we want to > > have the workflow before switching to git. > > Ok, let's talk about it. I goggled around and found out, that there are many possibility's with git like mirroring of svn etc. (http://blog.tfnico.com/2010/11/git-svn-mirror-for-multiple-branches.html) There is also Mercurial (HG) with Bitbucket and ongoing comparisations like "Git is Wesley Snipes, Mercurial is Denzel Washington and SVN is Morgan Freeman" It sounds more like a religious war between HG & GIT...but it seems to be, that git offers more features?! > I would like to use git as it makes submitting patches very easy and through github almost automated. I'm also thinking about moving > more docs into the repo, which would benefit from easy additions/patches (more about that later). It would probably also help the 1.x > faction to coordinate their stuff more flexibly. > > Comments? > > Dirk |
From: Dirk R. <dir...@gm...> - 2011-02-23 02:31:57
|
Hi Gerrit, On 02/22/2011 07:52 PM, Gerrit Voß wrote: > > hmm, while I like git for my local work I still would prefer a central repository that ensures > a linear history where the history can not be changed easily. I still run this combination > locally for repositories where groups of people can commit to. given that you're the one with the most GIT experience (well, definitely more than me) I'll defer to your judgment. > I feel that one has to change the workflow when transitioning to git and adapt > to the multi-repository model with a very limited set of comitters for a single repository > and pulls between repositories or patches per mail as the norm. I'm all for it. That's what I was thinking for SF with you, me and Carsten for OpenSG2 and Johannes, Patrick and somebody else from Darmstadt for 1. > Just replacing svn by git and go on like before does not seem to be the best approach to me. > IMHO we need to put in a little more thinking about how we want to have the workflow > before switching to git. Ok, let's talk about it. I would like to use git as it makes submitting patches very easy and through github almost automated. I'm also thinking about moving more docs into the repo, which would benefit from easy additions/patches (more about that later). It would probably also help the 1.x faction to coordinate their stuff more flexibly. Comments? Dirk |
From: Gerrit V. <vo...@vo...> - 2011-02-23 01:47:47
|
Hi, Am Feb 23, 2011 um 2:10 AM schrieb Dirk Reiners <dir...@gm...>: > > Hi All, > > On 02/22/2011 08:55 AM, Michael Raab wrote: >> Hi, >> >> two questions on that issue: >> >> 1.) What is planned to be final solution for the 1.8 repository? SVN? >> 2.) Is there an estimate when this solution could be ready? > > Given that SF supports a lot more VCSs and in general seems to be much more active now there is very little reason to run our own server for this. Now the question is what to use. A bunch of people on the project use (and apparently like) git, mostly using github for their work, so git is probably the preferred system. SF would serve as the master/stable repository, work repos would be on github. > > So here's my proposal: > > - Migrate SF CVS to SF GIT as a OpenSG_1 repository. I have a cvs2git.options file attached that I tried and the results seem ok to me. I would need input from anybody that has committed to OpenSG 1 if they're ok with putting their name/email (and which one) into this. I extracted the following list from CVS: > > > If you are on this list and want to have an email in the conversion, please let me know privately. If you don't want your name in here please let me know, too, and I will use the CVS Unix name. > > - Migrate the OpenSG.org SVN to SF GIT as OpenSG_2 repository. I know Gerrit has a live link between his git and svn, so that should be easy to do. > - Turn off SVN and CVS on SF, and the SVN on opensg.org, make SF GIT the official repo. > hmm, while I like git for my local work I still would prefer a central repository that ensures a linear history where the history can not be changed easily. I still run this combination locally for repositories where groups of people can commit to. I feel that one has to change the workflow when transitioning to git and adapt to the multi-repository model with a very limited set of comitters for a single repository and pulls between repositories or patches per mail as the norm. Just replacing svn by git and go on like before does not seem to be the best approach to me. IMHO we need to put in a little more thinking about how we want to have the workflow before switching to git. just my 0.02€ kind regards gerrit |
From: Carsten N. <car...@gm...> - 2011-02-23 00:32:41
|
Hi Dirk, On 02/22/2011 12:10 PM, Dirk Reiners wrote: > So here's my proposal: > > - Migrate SF CVS to SF GIT as a OpenSG_1 repository. I have a > cvs2git.options file attached that I tried and the results seem ok to > me. I would need input from anybody that has committed to OpenSG 1 if > they're ok with putting their name/email (and which one) into this. I > extracted the following list from CVS: > > - Migrate the OpenSG.org SVN to SF GIT as OpenSG_2 repository. I know > Gerrit has a live link between his git and svn, so that should be easy > to do. hmm, only thing I'm not sure about is what happens to branches in the SVN. I usually use git-svn to only get the trunk, not sure if Gerrit imports the whole repository. Do we care about any of the branches in SVN (last commit to any of them was at r1828 2 years ago)? FWIW branches/Carsten_PtrWork and branches/Carsten_PtrWork2 are definitely dead ;) > - Turn off SVN and CVS on SF, and the SVN on opensg.org, make SF GIT the > official repo. > > Comments? would be nice to have the repos in one place again, in other words I like the idea. Cheers, Carsten |