similar to: Time for a distributed VCS?

Hi, I have been looking at mirroring the SVN R repository into a DVCS (Mercurial, Git, bzr, etc...). The idea would be to have that as an always up-to-date untouched master (a mirror) but having it in a DVCS would make forks easier to make and maintain, and possibly ease up the process of having patches included upstream. Would anyone else be interested ? Laurent

Hi, all, This isn''t about rspec, but this list has people whose opinions I respect. So, I''m looking for a new version control system for my local development. I was going to install subversion, but I''ve heard rumors of people using some newer ones. Thoughts? I''d like to be able to run it either locally or on a home server. If I run it off a home server, then

Jason Kim <jasonwkim at google.com> writes: > On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote: > > Besides, the git-svn readonly bridge is a great solution for those who want to use git > >   It seems to be a reasonable solution for those individuals who > want to use git, but in my experience not for organizations that >

Hi, Just wondering whether anyone had thought about moving the R sources to a "distributed" version control system such as Bazaar, Git or Mercurial. These new generation systems make it easier to work on feature branches, allow working offline, are very fast, etc. Some projects that have moved to Git are Linux Kernel Perl Ruby on Rails ... http://en.wikipedia.org/wiki/Git_(software)

Full_Name: Ben Goodrich Version: 2.6.1 OS: Debian Submission from: (NULL) (128.103.222.166) bzr is another version control system and adds a .bzr folder to the top-level directory of a package, similar to .svn and .git for subversion and git respectively. However, while R CMD build removes directories called .svn, .git, and some others, it does not remove .bzr . As a result, the .bzr folder is

Hi, I was wondering if it is possible to put a dovecot managed maildir under a vcs like system, for example git or bzr. I'd like to have a seamless history of all mail going in and out of my mailboxes, so a vcs like system seams a good choice for me. I'm not quite sure however if that would cause any problems to dovecot and what the best way of handling commits would be. If anyone on the

Time ago when the svn server was crawling due to massive hammering from people mirroring the repo, someone said that after the 2.6 release we could discuss creating official mirrors for those who work with svn clients based on distributed VCSs such as git and bazaar. Such mirrors increase productivity (facilitating experimentation and parallel tasks, allowing off-line work) and even lessens the

https://bugzilla.samba.org/show_bug.cgi?id=7957 Summary: rsync -C should include .hg (it already includes .git and .bzr) Product: rsync Version: 3.0.7 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org

On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes wrote: > One thing that I wanted to see (and probably missed, because I didn't > read all the thread) is to discuss the workflow. I'm under the > impression that not all regular LLVM developers understand the > implications for the LLVM community of migrating from a central VCS to a > distributed one, on terms of

fly language <flylanguage at gmail.com> writes: >> After git, mainline will still be the most important branch for the >> *project*, >> but you will work with quite a few branches on parallel. >> >> > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to > maintain the "mainline". > > The git workflow works really

A little patch to add Wx::GenericDirCtrl. A non-native control (on OS X at least) but maybe useful to someone. I have tested it but think it should just be added to controls.rb sample - will do later when i have fixed some other probs with that. Also, I''ve started putting class-specifc style constants in the relevant .i file, as discussed previosuly - will submit a patch doing this

Chris Lattner <clattner at apple.com> writes: > I really do appreciate distributed VCS, but only as staging. > Incremental development is crucial for the project and "take this git > push with 100K of code" will never be acceptable. Incremental development is probably promoted by DVCS far more than others. Your comment seems to imply that only the tip of each push is

Thank you everyone for your participation. A few flaws in my poll: 1) Favoring Git: Subversion supporters are more likely to be split between the last two options. 2) Favoring SVN: Timing of the poll went from Friday night to Monday morning, which probably favored the open source community to 9-to-5ers on private forks. 3) Favoring radicals: Too easy to cheat. Requiring a login or email address

On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote: >> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and

Launchpad already maintains bzr mirrors: http://code.launchpad.net/llvm The mirrors are the lp:~vcs-import branches (a specific launchpad user used for automatically mirroring branches). Baptiste. 2009/10/28 Óscar Fuentes <ofv at wanadoo.es> > Time ago when the svn server was crawling due to massive hammering from > people mirroring the repo, someone said that after the 2.6 release

I attach a basic State of Art: ########################################################################################################################################## # State of Art Analysis of Git vs SVN ########################################################################################################################################## Scopus Keywords: GIT AND SVN

Chris Lattner <clattner at apple.com> writes: > I completely agree. The "branch" I most care about is mainline, and > losing the ability to say "fixed in r1234" (with some sort of > monotonically increasing number) would be a tragic loss. The monotonically increasing number is useful for giving you a fuzzy idea about how that change relates to other changes

UNBIASED FACTS: ? Bugzilla & R-devel Mailing Lists: Remain unchanged: Understood as Ticketing platforms for bug pull requests on the R-devel Git Repository. ? Git Repository Options: A) Github (Cloud with Automated backups from GitHub to CRAN Server): https://github.com B) Gitlab (Selfhosted on CRAN): https://about.gitlab.com C) Phabricator (Selfhosted on CRAN): https://www.phacility.com D)

On Oct 28, 2009, at 8:30 AM, Óscar Fuentes wrote: > Time ago when the svn server was crawling due to massive hammering > from > people mirroring the repo, someone said that after the 2.6 release we > could discuss creating official mirrors for those who work with svn > clients based on distributed VCSs such as git and bazaar. > > Such mirrors increase productivity

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > The core issue here is that you are effectively telling us > that the current workflow is not supported by Git. No, it's fully supported. We can even run things exactly the same way. But we don't _have_ to do that. > You are also telling us that the current workflow is in some way wrong > or misguided or