Berkeley CSUA MOTD:Entry 54353
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2017/12/16 [General] UID:1000 Activity:popular
12/16   

2012/4/2-6/4 [Computer/SW/Languages/Java, Computer/SW/RevisionControl] UID:54353 Activity:nil
4/02    We use Perforce at work for revision control. It seems to work okay.
        Lately, a lot of the newer developers are saying that Perforce
        sucks and we should switch to Mercurial or Git. I have done some
        searching on the Internet and some others have this opinion. Added
        advantage is that Mercurial and Git are free. However, there would
        be some work to switch for the sysadmins and the developers.
        Is it worth it or do people just like what's shiny?
        \_ I *love* git but there are good reasons to use Perforce. Do they hold
           for you? http://stevehanov.ca/blog/index.php?id=50
        \_ I *love* git but there are good reasons to use Perforce. Do they
           hold for you? http://stevehanov.ca/blog/index.php?id=50
           \_ That post pretty much describes my experiences with git and p4.
              Unlike the author, I do use the distributed stuff in git (it's
              nice to have a local repository when you're working from home),
              but everything else is right on.
           \_ We're moving from Perforce to Git. Too many branches and pushing
              code around is painful. Idea is to properly componentize the platform
              and apps, and have 1 repo per jar, stored our GitHub-FI. Let maven
              download the dependencies and do the build locally. We'll see...
              code around is painful. Idea is to properly componentize the
              platform and apps, and have 1 repo per jar, stored our
              GitHub-FI. Let maven download the dependencies and do the build
              locally. We'll see...
        \_ These "new" developers want the latest and greatest. Hint. It's
           not about the language or the revision control system. It's how
           you use them. There are 10000s of ways to use Git. What is the
           convention you guys agreed on? That is more important that anything
           else. What happens if architect A wants to use convention A and
           another architect insists on using convention B and they're
           incompatible and you end up with a massively distributed unmergeable
           monster and end up bifurcating the code base? You're FUCKED!!!
           Another thing: having a code-review system is much more important
           than the revision control system. If you don't know what that is
           or understand why that is more important than language/system/platform
           then you should not be in a position to make this type of decision.
           What is your position in the company and are you in the position
           to make this type of decision?
           or understand why that is more important than language/system/
           platform then you should not be in a position to make this type of
           decision. What is your position in the company and are you in the
           position to make this type of decision?
2017/12/16 [General] UID:1000 Activity:popular
12/16   

You may also be interested in these entries...
2008/1/10-12 [Computer/SW/RevisionControl] UID:48922 Activity:nil
1/10    In subversion (svn) is there a way to check out a file from
        a different BRANCH for diff purposes?
        \_ More specifically, do you want to compare your working copy of
           file.c with one in a branch?  Or do you want to compare the
           repository copy of file.c in trunk vs. file.c in branch?
           \_ compare a particular revision in trunk with a particular
	...
2007/10/3-7 [Computer/SW/RevisionControl] UID:48238 Activity:high
10/3    Is there a command in cvs that'll tell me what files I've
        editted/changed from the original cvs update?  \_ Use the -n flag.
        I normally use cvs -n update.  \_ Do you have to use CVS or can
        you migrate to something else?
           \_ Yeah, subversion is quite nice.  I hated it at first, though
              \_ How do you find out what files I've editted in svn?
	...
2006/10/24-26 [Computer/SW/WWW/Browsers] UID:44940 Activity:low
10/24   So why is Firefox at 2.0 now?  Granted this revision is a bit bigger
        than most minor revisions, but neither the program architecture or
        plugin interface changed much.
        \_ Marketing?  Maybe even free software needs marketing?
           \_ The marketing wants to be freeeeee!!1111
        \_ http://www.mozilla.com/en-US/firefox/2.0/releasenotes/#whatsnew
	...
2006/6/14-16 [Computer/Companies/Apple, Computer/SW/OS/OsX] UID:43382 Activity:nil
6/14    I am thinking of getting a 17" Macbook Pro to replace my 17"
        Powerbook G4. I haven't been following CPUs lately. Is there any
        reason to wait (i.e. something better is just around the corner)?
        \_ merom is supposed to be released around september.  it will be
           64 bit and use less power than the current chip.  if you can wait
           that long, you might as well.
	...
2006/5/18-22 [Computer/HW/Laptop] UID:43095 Activity:nil
5/18    I want to use version control for some code on my laptop even when
        I'm not connected to the network with the SVN repository. Is there
        a good way to run a local svn repository on the laptop and synch it
        with the main repository from time to time? ok tnx.
        \_ http://svk.elixus.org  (haven't used it personally)
           but you might want to think about a revision control system that's
	...
Cache (8192 bytes)
stevehanov.ca/blog/index.php?id=50
Why Perforce is more scalable than Git Posted on: 2009-02-23 21:31:22 Okay, say you work at a company that uses Perforce (on Windows). So you're happily tapping away using perforce for years and years. Perforce is pretty fast -- I mean, it has this "nocompress" option that you can tweak and turn on and off depending on where you are, and it generally lets you get your work done. If you change your client spec, it synchronizes only the files it needs to. Perforce is great, why would you ever need anything else? Once you've experienced git, there is no going back, man. You might have checked out firefox -- but have you checked out firefox ooon GIT? Want to store your changes temporarily to work on something else? Want to automatically detect out of bounds array accesses and add missing semicolons to all your code? "git umm-nice-try" Branching on git is like opening a new tab in a browser. And you wrote the code, so you get to merge it back in, because you are the expert. Branching on Perforce is kind of like performing open heart surgery. It should only be done by professionals: experts in the art who really know what they are doing. You have to create a "branch spec" file using a special syntax. If you screw up, the entire company will know and forever deride you as the idiot who deleted "//depot/main". Now, if you have been using git for a few days you might discover this tool called "git-p4". you might say, "I can import from my company's p4 server into git and work from that, and then submit the changes back when I am done," you might say. It's just a big python script, and it works by downloading the entire p4 repository into a python object, then writing it into git. If your repo is more than a couple of gigs, you'll be out of memory faster than you can skim reddit. hack up git-p4 to do things a file at a time in about an hour. The real problem is: Git can't handle large repositories Okay this is subjective because it depends on your definition of large. Because your company's source tree is probably that large. Maybe you check in binaries of all your build tools, or maybe for some reason you need to check in the object files of the nightly builds, or something silly like that. P4 can handle this because it runs on a cluster of servers somewhere in the bowels of your company's IT department, administered by an army of drones tending to its every need. when it started to show its strain, Larry Page personally went to Perforce's headquarters and threatened to direct large amounts of web traffic up their executives' whazzoos until they did something about it. The typical git user considers the linux kernel to be a "large project". Linus's git rant on Google code, take a listen to see how he sidesteps the question of scalability. Go ahead and wait a minute after every git command while it scans your entire repo. I don't think many people really use distributed source control. Most git users (especially those using Github) use the centralized model anyway. Ask yourself this: Is it really that important to duplicate the entire history on every single PC? Do you really need to peruse changelist 1 of KDE from an airplane? What you really want is the other stuff: easy branching, clean, and stash, and the ability to transfer changes to another client. The distributed stuff isn't really asked for, or needed. Just give me a version control system that lets me do these things and I'll be happy: * Let me merge changes into my coworker's repos, without having to check them in first. git folder, when this could be stored on a central server. Subscribe to posts Post comment Real Name: Your Email (Not displayed): Text only. No HTML If you write "http:" your message will be ignored. Choose an edit password if you want to be able to edit or delete your comment later. Editing Password (Optional): Post Holger Schurig 2009-03-14 19:14:09 Try "git clone --depth 0". Edit zzz 2009-03-14 20:04:08 Git was designed to be a version control tool - no a quasi- file-server 'repository' which is how most other tool like Subversion and Perforce are actually used. It was also not designed to track a whole set of unrelated projects - say a teams entire code-base, something that both Linus and then Randall made pretty clear. Track each project as a single Git repository, and if you need to tie them together, create a master repository that included each one as a sub-module. The flexibility you gain from 'setting free' your individual projects is enormous, as it the smart use of a master repository that uses branches to create different mash-ups of your overall code-base. Edit Stephen Waits 2009-03-14 20:04:40 I've done some testing on big p4 repositories. A p4 sync takes less than one second, if no files have changed on the server. Git, plain and simple, does not scale to large repositories. That's OK, I guess, it's not really designed to handle that use case. Edit Stephen Waits 2009-03-14 20:07:27 @zzz, FWIW, we store all of our code and data in p4 because it's the Right thing to do. If I need to sync back a month to look at some issue, I need the specific data to be sync'ed back too. It stays out of our way, it's faster than anything out there. Edit zzz 2009-03-14 20:35:28 "we store all of our code and data in p4 because it's the Right thing to do" Well you may have identified another use case where Git is not ideal - really large binary blobs. I think the problem is Git has to checksum (sorry SHA1) all files it scans - and that would take some time on a 36GB file. To be fair, Git has always been advertised as a SCM - ie a source-code management system - and for that use-case it absolutely rocks IMO Personally I would still investigate a hybrid approach where you have the option of pulling just the source down to your lappy with Git, so if you are on the plane and you DO want to look at change-set 1 at least you can! Edit wcoenen 2009-03-14 20:36:51 Let me get this straight: you're saying perforce is faster than git for large projects? This surprises me because most git operations are completely off-line since all the data is local. I thought that operations which require network I/O are the slower ones. Care to back up your claim with a specific use case and some data? Edit jeremydw 2009-03-14 20:45:45 @ Jason P, an internal wrapper script for p4 that sends changelists to reviewers for reviews and approvals. To merge changes into a coworker's repo, why can't they just patch a CL? You don't have to submit a CL for a coworker to grab the changes. Edit albert 2009-03-14 20:50:40 "Let me merge changes into my coworker's repos, without having to check them in first." Would that be your coworkers distributed repository, by any chance? Edit NotAFan 2009-03-14 21:08:17 Perforce may scale well with regards to data size. In my experience it doesn't scaled well over a distributed network. Between having to check files out to work on them and tight integration with Visual Studio, if your link to the Perforce server does down you practically have to stop work. My one experience of Perforce was doing work with another company remotely. Combine that with Perforce lead to an incredibly frustrating experience. Edit SJS 2009-03-14 22:21:27 The one feature of a DVCS that I really really really like is the ability to use it as a sneakernet. Not all of the machines I develop on are connected to a network, or connected to the same network that the central/blessed repository is on. This I do not see as a feature -- if there's a central repository, it should be used as the mechanism of communication between developers. Sometimes I care, sometimes I don't (disk is cheap, but disk fills up faster still). Having an option for git to use either a local or a remote (central/blessed) repository would be nice. Disclaimer: I still use CVS, I've used Perforce (and liked it), and I use git (and like it), and I don't currently have an repositories that approach the sizes discussed in the article. Edit zzz 2009-03-14 23:10:09 "we store all of our code and data in p4 because it's the Right thing to do" Well you may have identified another use case where Git is not ideal - really large binary blobs. I...