Have to agree with Eduardo Felipe. We're doing the ~exact~ same thing here at our company, having a periodically git-svn synced repository to work on. AND I also had the same thought about creating github repositories to be synced regularly, it would be so much easier. Maybe it's because it's a more natural way to work? Food for thought.
Git allows people that do not have the rights for pushing upstream to still work and commit their changes in their branch (NOT sending patches on the ML, a pull request is just so much more convenient), and they could make their branches available to ~everyone~ instead of keeping them local like we're doing right now. It means more transparency in who did what, and more fine grained control upstream over what is merged, etc... The fear of having the project lead "stolen" by someone who does not push patches is groundless, because upstream always has much more momentum (look at all the other big projects using git) Seriously, SVN is a pain, the workflow is prehistoric. A github mirror would be a blessing. (And I know it's not what you wanted to talk about, really sorry about it) Regards Hugo Camboulive On Thu, Sep 9, 2010 at 10:59 PM, Eduardo Felipe <eduardofelip...@gmail.com> wrote: > On Thu, Sep 9, 2010 at 3:01 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: >> On Thu, Sep 9, 2010 at 1:49 PM, Leif Middelschulte >> <leif.middelschu...@gmail.com> wrote: >>> >>> Am 09.09.2010 um 18:41 schrieb Cedric BAIL: >>> >>>> On Thu, Sep 9, 2010 at 6:35 PM, Leif Middelschulte >>>> <leif.middelschu...@gmail.com> wrote: >>>>> Hey guys, >>>>> >>>>> with regards to the commit message part: >>>>> I think it might be an idea to formalize the header of a commit message >>>>> and make the server reject commits if necessary. >>>>> >>>>> Am 09.09.2010 um 18:22 schrieb Leandro Pereira: >>>>>> On Thu, Sep 9, 2010 at 1:15 PM, Gustavo Sverzut Barbieri >>>>>> <barbi...@profusion.mobi> wrote: >>>>>>> 4 - The fourth annoyance is related to the previous and is could be >>>>>>> called "commit torrent" or "ssh over svn" or "gcc over svn" and is the >>>>>>> result of people committing every line or test they do, then >>>>>>> committing couple of changes, then commit removing debug code, then >>>>>>> another fix... (...) >>>>>> >>>>>> *cough* git *cough* *cough* >>>>> As you know, a couple of weeks ago, I had a little poll [0] around. >>> As some already mentioned, I need to extend this poll by another one e.g. >>> "Which VCS would you like to use with EFL?". Still the outcomes of this >>> poll should be just seen as a hint for others who might want to give a sync >>> of servers/services a try. >> >> Let's take the VCS out of this thread, as I said Raster will not move, >> so even if we use git for one or another dev, the main tree will >> follow as SVN... and even moving to GIT, if we keep current commit >> quality (messages, torrents, ...) we'll have the aforementioned >> problems. > > If I can have my two cents, here it is: > > My company uses git-svn, with a "curated" version of EFL, internally. > We cherry-pick fixes and only get in sync with svn HEAD on > snapshots/releases. There's been a lot of discussion internally if we > should publish our repository on github, which I'm against as it would > look like a "fork of EFL" or something like it. That being said, I > honestly think that there should be a mirror of SVN on github, at > least for EFL (eina, evas, etc), so users who already are on git can > have a central place to do updates and create patches. > > Cheers, > > Eduardo Felipe. > > >> -- >> Gustavo Sverzut Barbieri >> http://profusion.mobi embedded systems >> -------------------------------------- >> MSN: barbi...@gmail.com >> Skype: gsbarbieri >> Mobile: +55 (19) 9225-2202 >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
