Re: [E-devel] [e-users] News from the E stables
Andrew Williams <[EMAIL PROTECTED]> - Tue, 27 Nov 2007 12:09:14 + >If folk are wanting better revision control and client-side diffing >etc. then SVN is a much wiser choice - not because it is better than >GIT, but because it looks the same to CVS users, requires absolutely >minimal re-learning (replace cvs with svn basically) and the >conversion is automated and simple. > >just 2 cents, I know that SVN is not perfect, but it is a few classes >above CVS. > >Andy > Hi all, being involved in big developments with CVS and SVN in industry, I would like to add my comments on this topic. We also use ClearCase and Aegis (+ a similar tool of our own) and Starteam. Beware of SVN. In particular on two critical points : - performances - ability to know what you're doing with branches No space here to elaborate on theses very special points but my 2 cents : - SVN could criple performances when commiting / updating ... - branches are in a very early and naive state of implementation, you could be lost in revision numbers just to merge 2 poor little files CVS offers less features but has a big advantage : it's very simple and crystal clear ! I agree with people that say that's bad to change the source control software near release time. That's not the moment : why make things harder in that particular time? But for the future I would suggest : - all must agree on centralized model - given that proper usage of source control software could be agreed - you may choose good tools even they implement distributed repository : it's just a matter of implementing good pratices in the team - git, monotone and darcs are very good tools - Aegis is a more robust tool that enable you to define a unique branch of integration : thus ensuring a good centralized model with strong features like change sets... That's said, the most features of the source control software the team would use, better the tracability and control will be ;). I.e. tagging releases, using scripts to make integration (apply a patch, merge a source tree, check good&bad files in working directories, maximize synthetic information and minimize differences... Cheers, Michel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
If folk are wanting better revision control and client-side diffing etc. then SVN is a much wiser choice - not because it is better than GIT, but because it looks the same to CVS users, requires absolutely minimal re-learning (replace cvs with svn basically) and the conversion is automated and simple. just 2 cents, I know that SVN is not perfect, but it is a few classes above CVS. Andy On 11 Nov 2007, at 16:25, Gustavo Sverzut Barbieri wrote: > On Nov 11, 2007 1:15 PM, Ulisses Furquim <[EMAIL PROTECTED]> wrote: >> Hi, >> >> On Nov 11, 2007 3:18 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: >>> I use git locally for doing branched development and push to CVS >>> when >>> at a stable point. It is sometimes a pain to sync things properly, >>> but >>> not that bad. >> >> Yes, I'm also doing this and it's a pain like you said (specially >> when >> you have to move files, rename, create directories, ...). Ah.. and >> I'm >> not even talking about "losing" history when you move/rename files in >> CVS. >> >>> For most people, there is not much benefit of using git >>> as they develop in a single branch. >> >> Yes, you're right, but that's why I said we'd have to change our >> workflow. With more people integrating and reviewing patches we'd >> have >> better code reaching the repository. And that will be very important >> with the stable version of our libs and apps. Moreover, think about >> maintaining version 1.0 of our libs and also the development version. >> We could create modules in CVS for the stable version and keep the >> development in the "old" module but that only becomes even more >> painful to work and doesn't scale, IMHO. > > Even right now, if you have to debug and find where things were > broken, you don't have a repo snapshot to test, you have to go > per-date and later do fine tuning on your files... it's really > unhelpful. > > The main problem is: people don't really use a SCM in E development, > just use something to publish your changes upstream... then sure, CVS > does that fine, but almost nothing more... since you don't use these > other things, then you don't really miss then. It's a real pitty. :-( > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] > MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Sunday, 11 November 2007, at 12:52:57 (-0300), Ulisses Furquim wrote: > Yes, CVS is working and that's exactly what keeps people not seeing > how better we would be with git. Being able to commit locally, > create branches to work on separate features and be able to merge > afterwards and so on. Once you work with git you notice how things > could be really easier and how painful it is to work with CVS. No, what people don't seem to understand is that we work on a different model from git. CVS and SVN are geared toward the model in which we work. git is not. > We could create modules in CVS for the stable version and keep the > development in the "old" module but that only becomes even more > painful to work and doesn't scale, IMHO. That's why you create branches. Yes, they work just fine in CVS. I've been using them for years. On Sunday, 11 November 2007, at 13:33:17 (-0300), Gustavo Sverzut Barbieri wrote: > every tool have its drawbacks and limitations, the problem is who is > trying to fix those. CVS, for sure, is not trying, neither SVN. Not true at all. Both CVS and SVN are under active development, as is git. The difference is that CVS and SVN are geared toward one particular development model; git is a completely different direction. The bottom line is, git is incompatible with the development model used in this project. SVN is a lot closer, but it still has major drawbacks and very few advantages. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "Karate is a form of martial arts in which people who have had years and years of training can, using only their hands and feet, make some of the worst movies in the history of the world." -- Dave Barry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Carsten Haitzler <[EMAIL PROTECTED]> wrote: > Looking at major end user interface, one can see that Compiz-Fusion, > in the Linux world, is becoming the favored desktop for a lot of > people, and, in the Windows world, you should agree that > Windows Vista has became nice to look at ;) not sure about that - but lets see. Personally, I like the idea of getting E17 out, then maybe a patch later on for Compiz/Beryl would be awesome. That's where the focus should be (as you have mentioned, it is). If E17 can get out by the end of the year (at least a good beta version) that would be an awesome feat I think. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Nov,Saturday 10 2007, at 3:46 PM, Michel BRIAND wrote: > Hi, > > Fist, your involvement and wisdom as team leader is respected and > appreciated ! > > Ulisses said: >> Formalising can be a good thing, I think. We could even try to change >> our workflow and start using git. What do you think? >> > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > that's prevented devs from tagging releases in the past. > > Since there are many "packages" (libs & apps) to manage in parallel, > and provided that there is often large impact after a lib change, it's > of a good value to think about defining good procedures to > commit, update, build and test. > > So the good script e17_build should be included in the main source > tree, > and improved so that everything is built & tested against either > (quick) > "latest" source tree, either (better) "tagged" releases. For regression testing I want to suggest this framework. It was written this Summer of Code. [1] for NetBSD, but it can be easily used in other projects.It is designed to run, compile regression tests from C, shell and report them in txt or XML file. XML can be easily converted to nice html page. [1]http://www.netbsd.org/~jmmv/atf/ Regards Adam. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Tue, Nov 13, 2007 at 03:48:22PM +1100, Carsten Haitzler wrote: > On Sat, 10 Nov 2007 15:46:44 +0100 Michel BRIAND <[EMAIL PROTECTED]> babbled: > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > > that's prevented devs from tagging releases in the past. > > it is? how much more local disk space will this take up? keeping lots of > revision history locally is going to eat up local space. it's going to kill > rsyncing of homedirs from box to box... i am wary of git. CVS is lean > client-side. Two cents from someone that uses git at work for projects: If CVS is working for you, don't change. It's painful to change to the new mindset that git gives you. Unless you need the ability to keep seperate branches and merge them for free, the pain probably isn't worth it. rsyncing of homedirs can slow down a little because of the number of files that will need to be stat'ed in the case of a mostly synced directory tree. However, git's compression is amazing, due largely to the way it packs filesystem objects. The Linux 2.6 git objects take about 200MiB, which is less than the actual checked out source. Branches and tags are nearly free in terms of diskspace, as they are just objects that reference other objects. > i see nothing slow about it. what's slow? note i use CVs from > japan/australia/asia and have no problems - it sits in the usa. so those in > the > usa will have even better service to it, and i can't see any problems with it > being slow. ? People typically complains about CVS slowness at doing checkouts, diff, and merge operations. git is extremely fast at these - it's typically done as fast as your shell can return the prompt. Granted, if you're not merging disparate branches 50 times a day, this makes no difference. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Sat, 10 Nov 2007 15:46:44 +0100 Michel BRIAND <[EMAIL PROTECTED]> babbled: > Hi, > > Fist, your involvement and wisdom as team leader is respected and > appreciated ! > > Ulisses said: > >Formalising can be a good thing, I think. We could even try to change > >our workflow and start using git. What do you think? > > > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > that's prevented devs from tagging releases in the past. it is? how much more local disk space will this take up? keeping lots of revision history locally is going to eat up local space. it's going to kill rsyncing of homedirs from box to box... i am wary of git. CVS is lean client-side. i see nothing slow about it. what's slow? note i use CVs from japan/australia/asia and have no problems - it sits in the usa. so those in the usa will have even better service to it, and i can't see any problems with it being slow. ? > Since there are many "packages" (libs & apps) to manage in parallel, > and provided that there is often large impact after a lib change, it's > of a good value to think about defining good procedures to > commit, update, build and test. > > So the good script e17_build should be included in the main source tree, > and improved so that everything is built & tested against either (quick) > "latest" source tree, either (better) "tagged" releases. > > It could sounds a bit hard but since the project has became (to our > satisfaction) larger, there are more devs, and consequently there are > more code clashes ;). In that way, everyone should think about "how > the rest of us would handle my changes?". the problem here is that you are trying to unify e as 1 big thing. that just makes management and releases worse. you want to SPLIT it up. you want to have separate development tracks so if 1 side-branch of work breaks - its just that branch affected. > Git does not provide it all, it's a tools that enable us to do it;). > Good practices, and good scripts, could make it real and help. i'm wary of git. it is a completely different model to which we have used for many many many years. changing scm will be a big change for us - everyone. it took x.org months to move to git. git also encourages people to hoard their own little repositories and "branches" instead of keeping it all together in 1 place to fetch/inspect/modify. we can keep our stuff in 1 place and not have to link that to having to build everything that happens to be in that 1 place. > Raster said: > >> 1. Identify people who WANT to be leaders and shape the direction of > >> E - and are willing to spent the effort. Some of you do it as a > >> hobby and love just that, some do it for a job, others are in > >> half-way houses. > > Some people are using EFL in their project. They know it's alpha > software. But they would benefit of a more paced & predictable cycle of > updates. yes. and to get there we need to finish off what we have and not add new ideas/things to it, but get what we have done and out the door. > More important, those people that make use of EFL to create applications > have a lot of problems that may help EFL development. A good interface > with those people seems to me a good value for the overall process. > > It's also a good testing ground if companies would support us, or would > invest in using EFL in their projects. > > Raster said: > >> But the primary thing of importance is getting E17 out the door. > > Oh yes ! > :^) > > Raster said: > >> I hope that everyone can be just as excited. I know I am. I smell a > >> new age of... Enlightenment. :) > > Yes ! I think it's a great opportunity. > > Vincent said: > > I was just wondering if it was the right time to start a new theme, > > which is a big big work. > > To my understanding it should not be a big big work. I don't know > precisely the difficulties, I only read the documentation of edje... > Improving this tasks by simplifying and standardizing theme creation > would be great ! > > One idea for the desktop shell ;o) : > > some colleagues and I, in the field of UNIX development & support, are > always searching for simple tools, portable, to create graphical > feedback in shell scripts... > > We went looking into tck/tk, perl/tk, xmessage, and a lot of > "dialog" tools programmable from the command line, on Linux, Solaris, > HP-UX, ... And as you probably know it's a mess ;o)... > > Beside this we always wondered why the "Open file" dialogs in all > graphical toolkits (gtk, qt, kde, ...) were so different, so far from > the user, > > If EFL file dialogs were usable in shell scripts it would be great. > Device handling facility (open usb disk of my E17 desktop, sending a > picture back to my desktop through bluetooth if I had E17 on my > mobile, ...) would be great also ;). > > So designing a good set of very basic "dialogs" with the very focus of > ergonomics in mind should be a central thing in e+evfs+desktop future. > Keeping the efficie
Re: [E-devel] [e-users] News from the E stables
On Sun, 11 Nov 2007 00:18:58 -0600 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled: > On Nov 10, 2007 7:07 PM, Brian 'morlenxus' Miculcy <[EMAIL PROTECTED]> wrote: > > > > Don't see why people want's to push git, cvs is working and i guess we > > have better things to do than changing the source management software. > > I have to agree with this sentiment. Unless we can demonstrate a real > benefit from the effort, this seems like another administrative > distraction. > > I use git locally for doing branched development and push to CVS when > at a stable point. It is sometimes a pain to sync things properly, but > not that bad. For most people, there is not much benefit of using git > as they develop in a single branch. bingo. git just is shuffling papers differently. cvs is not perfect. i have used cvs for a decade - and i have managed to write lots of code and collaborate with others for 10 years. git came about because the kernel never went into cvs - kernel devs just kept mailing patches to eachother and each with their own tree. they worked entirely differently. git works for their model. cvs has worked well for ours. when i work on stuff i tend to work locally without revision control - i dont see why i need it. i make a small change, i run and test - if it went bad, i fix it. when working live on stuff i tend to commit small changes often. i get an email on very commit that makes it sane to handle. what happens when we have git and now people keep separate branches and develop separately - then merge them - where does the oversight of such massive merges happen? how do we get git-commit mails so we see who is doing what where and when? if commit patches get massive we not longer can sanely review any of it and will just give up into chaos, OR we end up with barriers being put up - code cant move form one git tree to another until it has been reviewed and accepted (the kernel model). if there is a recipe for us grinding to a halt development-wise - that is a sure fire way of doing it. i am wary of git. i just can't see how it can really help. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Brian 'morlenxus' Miculcy <[EMAIL PROTECTED]> - Sun, 11 Nov 2007 02:07:32 +0100 >Never heard of that "good" script. Also we already have a nightly test >build running: http://download.enlightenment.org/tests/ >> Precisely : the script running on this server. It could be improved to help complete secured builds in developer's working directory. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Hi, On Nov 11, 2007 1:26 PM, dan sinclair <[EMAIL PROTECTED]> wrote: > > Like I said before we'd have to change our workflow to enjoy all the > > benefits of the decentralized nature of git. However, talking to > > Raster (on IRC) he had a very strong opinion of staying with CVS or > > changing to SVN (unlikely, though). > > GIT has it's own downsides. The main one, and a big one for us I > think, is that it will make people go off and develop features and > just bomb the trunk with them. Chunks of code that are too big to be > reviewed. I know people currently use the commit list to review > patches as they go in, and we send around patches before they're > committed. DVCS has a tendency to break this model. People wouldn't have to bomb the trunk with big patches full of new features. We could use more the mailing so people could submit series of patches for features and the responsible would integrate them (either using the patches in the e-mails or pulling directly from the author's tree). I'd say we just have to somehow adjust our workflow to extract the most from git. And I do believe it's all for the better. :-) > There are a couple of good articles by the SVN guys about this > behaviour: > http://blog.red-bean.com/sussman/?p=79 > http://blog.red-bean.com/sussman/?p=20 > http://web.mit.edu/~ghudson/thoughts/bitkeeper.whynot > > So, while GIT might be great. I don't think it's the right fit for E > development. At most, I'd say go to SVN but even then, CVS works. It > has its limitations but they're limitations we know and we've already > figured out how to deal with. Yes, it might not fit for E development where we just use CVS as a central repository (almost like backup only). How many of you have used "cvs log" for something useful? Have you seen "git log" or even "git log -p"? I do dare to say that we could develop better if we really used a good SCM and adopted good practices. > For people that want to use GIT on top of CVS, feel free. There is a > bit more pain but it's do-able. Yep, we're doing that already. -- Ulisses - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Nov 11, 2007 1:26 PM, dan sinclair <[EMAIL PROTECTED]> wrote: > On 11-Nov-07, at 10:52 AM, Ulisses Furquim wrote: > > Hi, > > > > On Nov 10, 2007 10:07 PM, Brian 'morlenxus' Miculcy > > <[EMAIL PROTECTED]> wrote: > >> On Sat, Nov 10, 2007 at 03:46:44PM +0100, Michel BRIAND wrote: > >>> Hi, > >> Hi > >>> > >>> Fist, your involvement and wisdom as team leader is respected and > >>> appreciated ! > >>> > >>> Ulisses said: > Formalising can be a good thing, I think. We could even try to > change > our workflow and start using git. What do you think? > > >>> > >>> Yes, git is a good trade, everyone noticed that CVS is so slow, and > >>> that's prevented devs from tagging releases in the past. > >> Don't see why people want's to push git, cvs is working and i guess > >> we > >> have better things to do than changing the source management > >> software. > > > > Yes, CVS is working and that's exactly what keeps people not seeing > > how better we would be with git. Being able to commit locally, create > > branches to work on separate features and be able to merge afterwards > > and so on. Once you work with git you notice how things could be > > really easier and how painful it is to work with CVS. > > > > Like I said before we'd have to change our workflow to enjoy all the > > benefits of the decentralized nature of git. However, talking to > > Raster (on IRC) he had a very strong opinion of staying with CVS or > > changing to SVN (unlikely, though). > > GIT has it's own downsides. The main one, and a big one for us I > think, is that it will make people go off and develop features and > just bomb the trunk with them. Chunks of code that are too big to be > reviewed. I know people currently use the commit list to review > patches as they go in, and we send around patches before they're > committed. DVCS has a tendency to break this model. This is totally bullshit. If you want to have CVS or SVN on top of GIT, you can, it's a subcase of the expected use, but the other way around is not true. > So, while GIT might be great. I don't think it's the right fit for E > development. At most, I'd say go to SVN but even then, CVS works. It > has its limitations but they're limitations we know and we've already > figured out how to deal with. every tool have its drawbacks and limitations, the problem is who is trying to fix those. CVS, for sure, is not trying, neither SVN. > For people that want to use GIT on top of CVS, feel free. There is a > bit more pain but it's do-able. we already do, even some branches are being published at http://staff.get-e.org, but many (me included) just push to CVS at later point, which make it good for development, but loose every history and other useful things. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On 11-Nov-07, at 10:52 AM, Ulisses Furquim wrote: > Hi, > > On Nov 10, 2007 10:07 PM, Brian 'morlenxus' Miculcy > <[EMAIL PROTECTED]> wrote: >> On Sat, Nov 10, 2007 at 03:46:44PM +0100, Michel BRIAND wrote: >>> Hi, >> Hi >>> >>> Fist, your involvement and wisdom as team leader is respected and >>> appreciated ! >>> >>> Ulisses said: Formalising can be a good thing, I think. We could even try to change our workflow and start using git. What do you think? >>> >>> Yes, git is a good trade, everyone noticed that CVS is so slow, and >>> that's prevented devs from tagging releases in the past. >> Don't see why people want's to push git, cvs is working and i guess >> we >> have better things to do than changing the source management >> software. > > Yes, CVS is working and that's exactly what keeps people not seeing > how better we would be with git. Being able to commit locally, create > branches to work on separate features and be able to merge afterwards > and so on. Once you work with git you notice how things could be > really easier and how painful it is to work with CVS. > > Like I said before we'd have to change our workflow to enjoy all the > benefits of the decentralized nature of git. However, talking to > Raster (on IRC) he had a very strong opinion of staying with CVS or > changing to SVN (unlikely, though). GIT has it's own downsides. The main one, and a big one for us I think, is that it will make people go off and develop features and just bomb the trunk with them. Chunks of code that are too big to be reviewed. I know people currently use the commit list to review patches as they go in, and we send around patches before they're committed. DVCS has a tendency to break this model. There are a couple of good articles by the SVN guys about this behaviour: http://blog.red-bean.com/sussman/?p=79 http://blog.red-bean.com/sussman/?p=20 http://web.mit.edu/~ghudson/thoughts/bitkeeper.whynot So, while GIT might be great. I don't think it's the right fit for E development. At most, I'd say go to SVN but even then, CVS works. It has its limitations but they're limitations we know and we've already figured out how to deal with. For people that want to use GIT on top of CVS, feel free. There is a bit more pain but it's do-able. dan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Nov 11, 2007 1:15 PM, Ulisses Furquim <[EMAIL PROTECTED]> wrote: > Hi, > > On Nov 11, 2007 3:18 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > > I use git locally for doing branched development and push to CVS when > > at a stable point. It is sometimes a pain to sync things properly, but > > not that bad. > > Yes, I'm also doing this and it's a pain like you said (specially when > you have to move files, rename, create directories, ...). Ah.. and I'm > not even talking about "losing" history when you move/rename files in > CVS. > > > For most people, there is not much benefit of using git > > as they develop in a single branch. > > Yes, you're right, but that's why I said we'd have to change our > workflow. With more people integrating and reviewing patches we'd have > better code reaching the repository. And that will be very important > with the stable version of our libs and apps. Moreover, think about > maintaining version 1.0 of our libs and also the development version. > We could create modules in CVS for the stable version and keep the > development in the "old" module but that only becomes even more > painful to work and doesn't scale, IMHO. Even right now, if you have to debug and find where things were broken, you don't have a repo snapshot to test, you have to go per-date and later do fine tuning on your files... it's really unhelpful. The main problem is: people don't really use a SCM in E development, just use something to publish your changes upstream... then sure, CVS does that fine, but almost nothing more... since you don't use these other things, then you don't really miss then. It's a real pitty. :-( -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Hi, On Nov 11, 2007 3:18 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > I use git locally for doing branched development and push to CVS when > at a stable point. It is sometimes a pain to sync things properly, but > not that bad. Yes, I'm also doing this and it's a pain like you said (specially when you have to move files, rename, create directories, ...). Ah.. and I'm not even talking about "losing" history when you move/rename files in CVS. > For most people, there is not much benefit of using git > as they develop in a single branch. Yes, you're right, but that's why I said we'd have to change our workflow. With more people integrating and reviewing patches we'd have better code reaching the repository. And that will be very important with the stable version of our libs and apps. Moreover, think about maintaining version 1.0 of our libs and also the development version. We could create modules in CVS for the stable version and keep the development in the "old" module but that only becomes even more painful to work and doesn't scale, IMHO. Regards, -- Ulisses - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Hi, On Nov 10, 2007 10:07 PM, Brian 'morlenxus' Miculcy <[EMAIL PROTECTED]> wrote: > On Sat, Nov 10, 2007 at 03:46:44PM +0100, Michel BRIAND wrote: > > Hi, > Hi > > > > Fist, your involvement and wisdom as team leader is respected and > > appreciated ! > > > > Ulisses said: > > >Formalising can be a good thing, I think. We could even try to change > > >our workflow and start using git. What do you think? > > > > > > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > > that's prevented devs from tagging releases in the past. > Don't see why people want's to push git, cvs is working and i guess we > have better things to do than changing the source management software. Yes, CVS is working and that's exactly what keeps people not seeing how better we would be with git. Being able to commit locally, create branches to work on separate features and be able to merge afterwards and so on. Once you work with git you notice how things could be really easier and how painful it is to work with CVS. Like I said before we'd have to change our workflow to enjoy all the benefits of the decentralized nature of git. However, talking to Raster (on IRC) he had a very strong opinion of staying with CVS or changing to SVN (unlikely, though). Regards, -- Ulisses - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Nov 10, 2007 7:07 PM, Brian 'morlenxus' Miculcy <[EMAIL PROTECTED]> wrote: > > Don't see why people want's to push git, cvs is working and i guess we > have better things to do than changing the source management software. I have to agree with this sentiment. Unless we can demonstrate a real benefit from the effort, this seems like another administrative distraction. I use git locally for doing branched development and push to CVS when at a stable point. It is sometimes a pain to sync things properly, but not that bad. For most people, there is not much benefit of using git as they develop in a single branch. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Sat, Nov 10, 2007 at 03:46:44PM +0100, Michel BRIAND wrote: > Hi, Hi > > Fist, your involvement and wisdom as team leader is respected and > appreciated ! > > Ulisses said: > >Formalising can be a good thing, I think. We could even try to change > >our workflow and start using git. What do you think? > > > > Yes, git is a good trade, everyone noticed that CVS is so slow, and > that's prevented devs from tagging releases in the past. Don't see why people want's to push git, cvs is working and i guess we have better things to do than changing the source management software. > > Since there are many "packages" (libs & apps) to manage in parallel, > and provided that there is often large impact after a lib change, it's > of a good value to think about defining good procedures to > commit, update, build and test. > > So the good script e17_build should be included in the main source tree, > and improved so that everything is built & tested against either (quick) > "latest" source tree, either (better) "tagged" releases. Never heard of that "good" script. Also we already have a nightly test build running: http://download.enlightenment.org/tests/ > > It could sounds a bit hard but since the project has became (to our > satisfaction) larger, there are more devs, and consequently there are > more code clashes ;). In that way, everyone should think about "how > the rest of us would handle my changes?". Can't see the more devs, currently a handful people works on efl/e, not really more than a year or two ago. > > Git does not provide it all, it's a tools that enable us to do it;). > Good practices, and good scripts, could make it real and help. > > Raster said: > >> 1. Identify people who WANT to be leaders and shape the direction of > >> E - and are willing to spent the effort. Some of you do it as a > >> hobby and love just that, some do it for a job, others are in > >> half-way houses. > > Some people are using EFL in their project. They know it's alpha > software. But they would benefit of a more paced & predictable cycle of > updates. > > More important, those people that make use of EFL to create applications > have a lot of problems that may help EFL development. A good interface > with those people seems to me a good value for the overall process. > > It's also a good testing ground if companies would support us, or would > invest in using EFL in their projects. > > Raster said: > >> But the primary thing of importance is getting E17 out the door. > > Oh yes ! > :^) > > Raster said: > >> I hope that everyone can be just as excited. I know I am. I smell a > >> new age of... Enlightenment. :) > > Yes ! I think it's a great opportunity. > > Vincent said: > > I was just wondering if it was the right time to start a new theme, > > which is a big big work. > > To my understanding it should not be a big big work. I don't know > precisely the difficulties, I only read the documentation of edje... > Improving this tasks by simplifying and standardizing theme creation > would be great ! Read more. Try yourself. > > One idea for the desktop shell ;o) : Below text is useless, we don't want to be windows vista or something else. Also can't see how you get an idea why the different open file dialogs are so far from the user... > > some colleagues and I, in the field of UNIX development & support, are > always searching for simple tools, portable, to create graphical > feedback in shell scripts... > > We went looking into tck/tk, perl/tk, xmessage, and a lot of > "dialog" tools programmable from the command line, on Linux, Solaris, > HP-UX, ... And as you probably know it's a mess ;o)... > > Beside this we always wondered why the "Open file" dialogs in all > graphical toolkits (gtk, qt, kde, ...) were so different, so far from > the user, > > If EFL file dialogs were usable in shell scripts it would be great. > Device handling facility (open usb disk of my E17 desktop, sending a > picture back to my desktop through bluetooth if I had E17 on my > mobile, ...) would be great also ;). > > So designing a good set of very basic "dialogs" with the very focus of > ergonomics in mind should be a central thing in e+evfs+desktop future. > Keeping the efficiency of EFL, portable as it is, fast, beautiful, > simple > > Looking at major end user interface, one can see that Compiz-Fusion, > in the Linux world, is becoming the favored desktop for a lot of > people, and, in the Windows world, you should agree that > Windows Vista has became nice to look at ;) > > Best regards, > Michel > Regards, Brian 'morlenxus' Miculcy > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___
Re: [E-devel] [e-users] News from the E stables
> One idea for the desktop shell ;o) : > > some colleagues and I, in the field of UNIX development & support, are > always searching for simple tools, portable, to create graphical > feedback in shell scripts... > > We went looking into tck/tk, perl/tk, xmessage, and a lot of > "dialog" tools programmable from the command line, on Linux, Solaris, > HP-UX, ... And as you probably know it's a mess ;o)... > > Beside this we always wondered why the "Open file" dialogs in all > graphical toolkits (gtk, qt, kde, ...) were so different, so far from > the user, > > If EFL file dialogs were usable in shell scripts it would be great. > Device handling facility (open usb disk of my E17 desktop, sending a > picture back to my desktop through bluetooth if I had E17 on my > mobile, ...) would be great also ;). > > So designing a good set of very basic "dialogs" with the very focus of > ergonomics in mind should be a central thing in e+evfs+desktop future. > Keeping the efficiency of EFL, portable as it is, fast, beautiful, > simple > Enity in cvs (might need some fixing) allowsy you to pop up dialogs, populate them, get trees etc (like GTK's Zenity) using shell scripts, perl, etc... Give it a try if you're looking for something like that. -- Hisham Mardam Bey http://hisham.cc/ +1-514-713-9312 Codito Ergo Sum (I Code Therefore I Am) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On Saturday, 10 November 2007, at 15:46:44 (+0100), Michel BRIAND wrote: > everyone noticed that CVS is so slow, and that's prevented devs from > tagging releases in the past. Rubbish. Nothing has kept devs from tagging releases in the past except the fact that they simply didn't do it. Every Eterm release for quite some time has been tagged. As a non-developer, you don't know what we can/can't do or why things have/have not been done a certain way, so don't act like you do. > It could sounds a bit hard but since the project has became (to our > satisfaction) larger, there are more devs, and consequently there > are more code clashes ;). In that way, everyone should think about > "how the rest of us would handle my changes?". Define "code clashes." If you mean "conflicts," I question how you would know that since you do not commit code and could not have experienced another developer's code conflicting with code you were going to commit. > We went looking into tck/tk, perl/tk, xmessage, and a lot of > "dialog" tools programmable from the command line, on Linux, > Solaris, HP-UX, ... And as you probably know it's a mess ;o)... > > Beside this we always wondered why the "Open file" dialogs in all > graphical toolkits (gtk, qt, kde, ...) were so different, so far > from the user, > > If EFL file dialogs were usable in shell scripts it would be great. > Device handling facility (open usb disk of my E17 desktop, sending a > picture back to my desktop through bluetooth if I had E17 on my > mobile, ...) would be great also ;). > > So designing a good set of very basic "dialogs" with the very focus > of ergonomics in mind should be a central thing in e+evfs+desktop > future. Keeping the efficiency of EFL, portable as it is, fast, > beautiful, simple So far you're the only one who's expressed interest in such a thing, so the onus is really on you to follow through with it. > Looking at major end user interface, one can see that Compiz-Fusion, > in the Linux world, is becoming the favored desktop for a lot of > people, and, in the Windows world, you should agree that Windows > Vista has became nice to look at ;) I don't see what that has to do with anything Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "When I was in prison, I was wrapped in all those deep books. That Tolstoy crap. People shouldn't read that stuff." -- boxer Mike Tyson on what he read before he decided he preferred comic books - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
Hi, Fist, your involvement and wisdom as team leader is respected and appreciated ! Ulisses said: >Formalising can be a good thing, I think. We could even try to change >our workflow and start using git. What do you think? > Yes, git is a good trade, everyone noticed that CVS is so slow, and that's prevented devs from tagging releases in the past. Since there are many "packages" (libs & apps) to manage in parallel, and provided that there is often large impact after a lib change, it's of a good value to think about defining good procedures to commit, update, build and test. So the good script e17_build should be included in the main source tree, and improved so that everything is built & tested against either (quick) "latest" source tree, either (better) "tagged" releases. It could sounds a bit hard but since the project has became (to our satisfaction) larger, there are more devs, and consequently there are more code clashes ;). In that way, everyone should think about "how the rest of us would handle my changes?". Git does not provide it all, it's a tools that enable us to do it;). Good practices, and good scripts, could make it real and help. Raster said: >> 1. Identify people who WANT to be leaders and shape the direction of >> E - and are willing to spent the effort. Some of you do it as a >> hobby and love just that, some do it for a job, others are in >> half-way houses. Some people are using EFL in their project. They know it's alpha software. But they would benefit of a more paced & predictable cycle of updates. More important, those people that make use of EFL to create applications have a lot of problems that may help EFL development. A good interface with those people seems to me a good value for the overall process. It's also a good testing ground if companies would support us, or would invest in using EFL in their projects. Raster said: >> But the primary thing of importance is getting E17 out the door. Oh yes ! :^) Raster said: >> I hope that everyone can be just as excited. I know I am. I smell a >> new age of... Enlightenment. :) Yes ! I think it's a great opportunity. Vincent said: > I was just wondering if it was the right time to start a new theme, > which is a big big work. To my understanding it should not be a big big work. I don't know precisely the difficulties, I only read the documentation of edje... Improving this tasks by simplifying and standardizing theme creation would be great ! One idea for the desktop shell ;o) : some colleagues and I, in the field of UNIX development & support, are always searching for simple tools, portable, to create graphical feedback in shell scripts... We went looking into tck/tk, perl/tk, xmessage, and a lot of "dialog" tools programmable from the command line, on Linux, Solaris, HP-UX, ... And as you probably know it's a mess ;o)... Beside this we always wondered why the "Open file" dialogs in all graphical toolkits (gtk, qt, kde, ...) were so different, so far from the user, If EFL file dialogs were usable in shell scripts it would be great. Device handling facility (open usb disk of my E17 desktop, sending a picture back to my desktop through bluetooth if I had E17 on my mobile, ...) would be great also ;). So designing a good set of very basic "dialogs" with the very focus of ergonomics in mind should be a central thing in e+evfs+desktop future. Keeping the efficiency of EFL, portable as it is, fast, beautiful, simple Looking at major end user interface, one can see that Compiz-Fusion, in the Linux world, is becoming the favored desktop for a lot of people, and, in the Windows world, you should agree that Windows Vista has became nice to look at ;) Best regards, Michel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] News from the E stables
On 11/5/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > I also see the team growing - this is great, but it serves to just increase > communication traffic, and that in turn means less coding gets done. The > traditional solution here is to start some hierarchy and "reporting lines". I > don't want to do this though - this will server to create splits where once > there was fluid freedom. If we must - we must. Any suggestions? I'm thinking > of > maybe just formalising a bit more of our developer "Relations", involvement > and > teamwork. Some Ideas for people-things: Formalising can be a good thing, I think. We could even try to change our workflow and start using git. What do you think? > 1. Identify people who WANT to be leaders and shape the direction of E - and > are willing to spent the effort. Some of you do it as a hobby and love just > that, some do it for a job, others are in half-way houses. > 2. Lets have actual weekly or monthly developer meetings - literally all-in > live > discussions - maybe IRC? Have actual agendas in meetings. Minutes. Please, let's use IRC. > 3. Have regular community meetings where people can tell us what they like and > don't - give feedback or whatever. > 4. Try an organise some annual get-together. An "E meet" (I think I'll just > call it "The Rave" for now - it fits with the whole E thing). So Literally > find > a place on the planet we all can/want to go to - go there. Sounds good! :-) > Now we also need to fix up enlightenment.org a bit - I intend to sink a bit of > time into solidifying some content. The Wiki has a fair bit. Anyone is welcome > to contribute as they see fit. Andres (dresb) already did a major writing/rewriting/reorganization on the wiki. It's a good starting point.. > But the primary thing of importance is getting E17 out the door. It's actually > looking petty good. Only 2 really big TODO items left. I'm doing a theme > revamp. The Default theme has very much aged. The gold bling isn't incredibly > popular. When I first saw the gold bling it was awesome! :-) But after some time it became annoying, I have to say. > I'm working on something I think people will love - and it still shows > off E. It will replace the current default - and will also knock off some of > the "comment the default theme so its better documented for people to build > new > themes from and learn Edje. Nice! > I hope that everyone can be just as excited. I know I am. I smell a new age > of... Enlightenment. :) Let's start this new age, then. :-) -- Ulisses - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
