|
slipped posted:for what its worth, clearcase handles DB2 well, and I can't imagine git svn or any other RCS being able to handle a project of its size without some _serious_ changes to the current structure of things.
|
# ¿ Apr 11, 2009 07:27 |
|
|
# ¿ Apr 27, 2024 23:00 |
|
uXs posted:(And squashing history is even worse: you're not only changing history, you're actually destroying it. Destroying history in a version control system, think about it. Eww.)
|
# ¿ Aug 27, 2010 01:21 |
|
Help, an installer asked me to make a choice about how to install something!quote:Git pulls the entire repository to the hard disk of the user, so that all versions of all files are on your own system. The advantage of this is that you can do version control while being offline. That’s pretty nice, but not really relevant to my situation. I’m almost never offline when I’m coding. So I will be dealing mostly with the disadvantage of this approach: a lot of wasted hard disk space. According to this, git averages 1/2 the size of svn: git's versus svn's storage efficiency quote:All projects for which git is less storage efficient, are smaller than 100Kb. The projects for which git is most storage efficient (up to even 6 times for a certain C# project), are all of medium size (10–100MB) and code-heavy. For the other projects, which are blob heavy (eg. images), git and subversion are close (git beats svn by ~20%). Scaevolus fucked around with this message at 18:48 on Apr 14, 2011 |
# ¿ Apr 14, 2011 18:45 |
|
Captain Corny posted:That's still a dumb decision. If things are going the way I see them going, SVN will be replaced by Mercurial instead of Git, and Linus will have wasted two years of his life building Git while ignoring the platforms that the rest of the world was using. You're underestimating how many developers there are on Mac/Linux.
|
# ¿ Apr 14, 2011 19:52 |
|
Captain Corny posted:Rest of the thread: are you sick and tired of my little bitchfest yet?
|
# ¿ Apr 18, 2011 20:17 |
|
Fangs404 posted:The takeaway here is that Mercurial isn't very good at handling large files. I'm sure that if I had a more beastly server with something like 4gb+ RAM, I would've been just fine, but know that Mercurial uses memory proportional to each file size on the receiving machine when pushing a repo.
|
# ¿ Dec 28, 2011 01:42 |
|
Plorkyeran posted:I almost never amend due to that I failed to figure out a way to get it to not ask me to edit the commit message each time, so making a new commit after every save and then squashing them later involves less disruption while working on things. code:
|
# ¿ May 8, 2014 01:03 |
|
here, this will replicate the SVN experience: git config --global --bool pull.rebase true (you probably shouldn't actually do this)
|
# ¿ Jun 21, 2014 03:35 |
|
|
# ¿ Apr 27, 2024 23:00 |
|
epalm posted:Awesome! You might find pretxncommit is slightly easier (you don't have to iterate through the changesets). I wrote an incoming hook to implement that sweet GitHub feature where issues are closed or referenced when commits mention them for our local Jira instance. Scaevolus fucked around with this message at 07:21 on Oct 9, 2014 |
# ¿ Oct 9, 2014 07:14 |