|
Janin posted:I've got a branch. To work on that branch, I need a large temporary file that takes time to generate. If I switch to another branch, I have two choices:
|
#
¿
Apr 18, 2009 15:53
|
|
|
|
| # ¿ May 2, 2024 08:39 |
|
|
Or you could put temp files where they go, instead of parceling them about the source tree like a temp file Johnny Appleseed and then bitching when your VCS makes that suck.
|
|
#
¿
Apr 18, 2009 17:36
|
|
|
krysmopompas posted:Similar situation - we've got about a 115gb depot on one project, mostly binary, with around 180 users hitting it. There are also 4 build machines constantly running and checking in ~500mb of compiled exe and script every 15 minutes to 2 hours. What's the point of storing builds in source control versus just using the file system?
|
|
#
¿
Jul 11, 2009 05:02
|
|
|
Seems like a lot of overhead for what you could achieve with tar, scp, and md5sum.
|
|
#
¿
Jul 11, 2009 05:34
|
|
|
Haha that sounds more like the proper speed of things.
|
|
#
¿
Jul 11, 2009 13:05
|
|
|
svn has only had non-poo poo merge tracking for about a year now, and if you're working in a shop with older Linux installs this can become frustrating. At a previous job I ended up going around and forcibly upgrading everyones FC9 svn install to something >= 1.5 because it wasn't backported into FC9 (at the time at least). Also, using svn with a reasonably large project (say, a Linux kernel tree) is slow and annoying. That's really the only bitch points I have about svn. Its pretty nice to use otherwise, though I think the dvcs model is a better way to work personally. svn is good enough that I can get by without hating life.
|
|
#
¿
Aug 8, 2009 03:25
|
|
|
nelson posted:So if your source files are ASCII text files and you or the people you work with are like me 1. This is awful advice 2. Even if you're a SCM-trashing moron, SCM does not preclude backups (well, you can make an argument for some DVCS systems...). Back your source control repositories up regularly!
|
|
#
¿
Jan 16, 2010 18:17
|
|
you may want to go with CVS.
|
nelson posted:Well, subversion dumps lots of local meta data files all over the place. When you're copying a directory from a different server to your local directory (this was a porting type project, had to get the latest code from the other developers who were on a separate repository before checking it into my repository), you end up copying all those meta data files too. Unfortunately, it really confuses the hell out of subversion when you do that. svn help export Learn to use your tools. EDIT: though I will agree, .svn directories suck.
|
|
#
¿
Jan 16, 2010 19:29
|
|
|
Rocko Bonaparte posted:I wonder if I understand how branches are supposed to work in git. I have a repository cloned that I've been pushing up for awhile now, but I have some speculative changes I'd like to do in a branch. I first create the branch with 'git checkout -b waaah' and then branch to it with 'git branch waaah.' I have found that if I edit a file there and then switch back to the master branch, the changes persist. Shouldn't it not persist into the master branch unless I merge it? Secondly, try committing changes to a branch before you expect the changes to be tracked by git.
|
|
#
¿
Jul 17, 2010 06:28
|
|
|
There is history that is useful and there is history that is useless. Git and similar systems let you have the ability to commit early commit often, and the ability to turn that into something that's high SNR later. I don't see anything wrong with that.
|
|
#
¿
Aug 27, 2010 01:38
|
|
|
Is it [url]http://[/url] or svn:// ? http is slow, especially for big repos.
|
|
#
¿
Sep 2, 2010 06:19
|
|
|
Git submodules are just you telling git that you're going to have a repository in your repository. Git will track the state of the submodule by the commit hash of some commit in the submodule. When you update the submodule (and presumably put these changes somewhere), in the parent repository you git add and git commit the submodule as if it were a file. The resulting diff will show you the old and new commit hash. In your specific case, I would expect you would need to fork oh-my-zsh, use the fork url for your submodule url, and manage changes to the submodule as you would any other project, except you would update your dotfiles repo when you wanted to point to a new commit in the submodule.
|
|
#
¿
Apr 21, 2012 20:38
|
|
|
|
| # ¿ May 2, 2024 08:39 |
|
|
Make the fix on a hotfix branch, put it in production, then rebase your feature branch or cherry pick that fix or merge it or really whatever suits your fancy.
|
|
#
¿
May 4, 2012 05:07
|
|