similar to: [LLVMdev] Version Control Upgrade?

Hi everyone, Reid said: > Of the tools available, it seems that only subversion, arch, and > monotone are suitable for our purposes. But, we'd love to hear your > thoughts; especially if you have first-hand experience with these tools. Apart from using CVS as a client (as everyone does), I've only ever used Aegis (previous employer, for ~3 years) and Perforce (the employer

John, Here's my list: 1. CVS is slow. Many of the other tools do bi-directional binary deltas on file changes they are transmitting. This is basically the technology that makes rsync so fast. CVS doesn't do this. Probably not a big deal when you're working at UIUC but its CRUCIAL when I'm on the road working from a hotel or airport wi-fi connection. 2. Related to 1 is diff

I have used Perforce also and fully agree it's wonderful. The only concern I have is with their license for open source projects. The only gotcha is that it must be renewed annually, and they reserve the right to not renew it (though they say they won't unreasonably deny renewals). Not sure how much this really matters, as Perforce strikes me as being one of those "do no

Hi all, My 2 cents as well: Here where I work (The MathWorks), we have hundreds of developers. We use CVS but we've had to write several thousand lines of Perl to make it useful to us (through revisions, branching, testing, and integration). Mercifully, we're planning on going to another system. In short, CVS doesn't scale well. It also doesn't having good branching capabilities

Reid Spencer wrote: > LLVMers, > > The oversight group has been kicking around the idea of getting a better > version control system than CVS. The problem is, we're not quite sure > what "better" means. So, we thought we'd ask your opinions. I think before we begin discussing which software to use, we should discuss what is really wrong with CVS (on a day to

Reid Spencer wrote: > John, > > Here's my list: > > 1. CVS is slow. Many of the other tools do bi-directional binary deltas > on file changes they are transmitting. This is basically the technology > that makes rsync so fast. CVS doesn't do this. Probably not a big deal > when you're working at UIUC but its CRUCIAL when I'm on the road working > from a

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

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

On Mon, 10 Jan 2005, John Criswell wrote: >> 5. CVS doesn't support distributed development well. Tools such as Arch >> and Monotone work on a peer-to-peer basis. No one computer is "the >> repository". If the CVS server should ever go down (heaven forbid), we'd ... > How important do you (and others) feel this feature is? I see this as being a pretty big

I''m a bit new to working on a rubyforge/sourceforge/open source project, so excuse my obliviousness. What is the preferred way of submitting a patch to wxruby? Thanks, Nick

On Sun, Jan 09, 2005 at 08:02:38PM -0800, Jeff Cohen wrote: > I have used Perforce also and fully agree it's wonderful. The only > concern I have is with their license for open source projects. The > only gotcha is that it must be renewed annually, and they reserve the > right to not renew it (though they say they won't unreasonably deny > renewals). Not sure how much

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)

LLVMers, The oversight group has been kicking around the idea of getting a better version control system than CVS. The problem is, we're not quite sure what "better" means. So, we thought we'd ask your opinions. There are three options, unless someone strongly advocates another solution: 1. Stay with CVS 2. Use Subversion 3. Use arch Some of the things we're trying to

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

Hi Currently devs check code into perforce and we have to checkout > package > update repo > deploy I know this could be scripted but are there any tools out there that can take code from a repository and build rpm's in a continuous integration type manner? I have been hunting around for such a tool and so far not seeing anything obvious as i dont want to reinvent the wheel if

>> Considering that everyone is managing just fine with cvs, anything >> discussed about the differences between cvs and *X* is not a show stopper. > > I would have used the term "coping just fine" with cvs. Yeah, it works. > But, is it productive? efficient? easy? fast? .. none of those. There > are better alternatives and that's why we're discussing it.

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > You know, this is exactly the crux of this whole "move to git" thread. > It is the very same problem of every other VCS migration I have seen (or > dealt with). The core issue here is that you are effectively telling us > that the current workflow is not supported by Git. It is supported, but if you want to

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

> 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 really great, but it does require getting rid of mainline thinking. It doesn't exist.

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