|
Modern Pragmatist posted:Git question here. You want release branches. git checkout -b 1.0 v1.0.0 will make a new branch based off of how your repository looked when you tagged v1.0.0, and you can then put bugfixes in there instead of in master. This lets you break poo poo in master and continue cutting bugfix releases (since you can just tag off of the 1.0 branch now). You can also usually merge 1.0 into master pretty easily and thus 1.1 or 2.0 or whatever will still contain all the bugfixes from your 1.0.x line.
|
#
?
Apr 28, 2011 18:01
|
|
|
|
| # ? May 10, 2024 14:58 |
|
|
bitprophet posted:You want release branches. git checkout -b 1.0 v1.0.0 will make a new branch based off of how your repository looked when you tagged v1.0.0, and you can then put bugfixes in there instead of in master. Great. Thanks for the insight.
|
|
#
?
Apr 28, 2011 18:35
|
|
|
Also keep in mind that you can copy commits via cherry-picking. If you have a commit on master tha specifically fixes a bug, switch to the release branch and cherry-pick it onto that, then release from there.
|
|
#
?
Apr 28, 2011 18:45
|
|
|
Also what is the best way to handle binaries? Currently I have a build folder that contains all files necessary to generate the binaries and I put the resulting binaries in dist:pre:/build/
setup.py
/dist/
Sorter_1.0.0.exe
Sorter_1.0.0.app
/source/
Sorter.py
configobj.py
|
|
#
?
Apr 28, 2011 19:28
|
|
|
Normally, you don't put generated files under version control, just the files used to generate them.
|
|
#
?
Apr 28, 2011 19:30
|
|
|
mr_jim posted:Normally, you don't put generated files under version control, just the files used to generate them. Ok that's what I assumed was the case. So I would include build but not dist.
|
|
#
?
Apr 28, 2011 19:31
|
|
|
Modern Pragmatist posted:Ok that's what I assumed was the case. So I would include build but not dist. Yes
|
|
#
?
Apr 28, 2011 19:48
|
|
|
My VCS experience has all been in Perforce and the current company is slowly migrating to Mercurial. I'm embracing it as best I can, but there's one nagging thing that I can't find a replacement / equivalent of in the new system... In Perforce, I'd have many changelists that I'd be working in at a time (let's ignore WHY I'm doing this for now). The closest I can find in Mercurial is the Shelve extension. Is this what I'm looking for or should I me making a bunch of branches to simulate the changelist behavior?
|
|
#
?
May 2, 2011 15:39
|
|
|
devilmouse posted:Perforce -> Mercurial Define 'changelist'. Edit: Oh, if you mean you're working on different features at the same time, then sure you could use branches, or you could also clone your repo for each feature.
|
|
#
?
May 2, 2011 15:51
|
|
|
Yeah - in Perforce a changelist is a group of files which you can check in separate from any other files you're working on. So I might have a changelist for a quick data change in XML, a changelist for some random bugfix in code, and a big changelist for a major feature. In Perforce, if someone randomly wanted another quick change, I could make a new changelist and check it in alone. I'm looking for the equivalence in Mercurial. Cloning the whole repo seems rather prohibitive given its size and the number of build scripts and config files I'd need to touch, so maybe branching is what I'm looking for.
|
|
#
?
May 2, 2011 16:01
|
|
|
I'm getting tired enough with git evangelism that I might go to CVS NT out of spite. Or maybe Fossil.
|
|
#
?
May 2, 2011 16:23
|
|
|
Why do you need some special feature to only commit some of the modified files?
|
|
#
?
May 2, 2011 17:18
|
|
|
Plorkyeran posted:Why do you need some special feature to only commit some of the modified files? Technically, I don't - but I don't relish the thought of keeping track of potentially 20+ file names out of a much larger list when I "hg st", thus the desire to organize them into changelists ala Perforce.
|
|
#
?
May 2, 2011 17:28
|
|
|
devilmouse posted:My VCS experience has all been in Perforce and the current company is slowly migrating to Mercurial. I'm embracing it as best I can, but there's one nagging thing that I can't find a replacement / equivalent of in the new system... In Perforce, I'd have many changelists that I'd be working in at a time (let's ignore WHY I'm doing this for now). The closest I can find in Mercurial is the Shelve extension. Is this what I'm looking for or should I me making a bunch of branches to simulate the changelist behavior? You could try using mercurial queues; I haven't used them before, but a quick scan of the docs shows they might do what you want. If your CLs have dependencies between them -- eg, you're splitting up a huge change into 3-4 CLs -- then you will probably just have to use 'hg st' and commit them separately. Depending on how awful this is, you could try writing a simple plugin that lets you tag open files and commit only files with a certain tag.
|
|
#
?
May 2, 2011 17:49
|
|
|
Janin posted:You could try using mercurial queues; I haven't used them before, but a quick scan of the docs shows they might do what you want. MQueues seem interesting, but they kind of make me afraid. They're always applied in order since they seem to be patchsets. I'm going to read up on them though. They might fit the bill. IntelliJ seems to have its own built-in faker changelists (and shelving, for that matter). It keeps an in-memory list of files and then just hg commit <file1> <file2> etc. But that seems both sketchy, and it would require using an IDE... Eww. I might just bite the bullet and write a quick bunch of scripts to deal with this on my own, but it seems like I'm being contrarian to what hg wants me to be doing anyway and not learning The True Way.
|
|
#
?
May 2, 2011 18:17
|
|
|
devilmouse posted:I might just bite the bullet and write a quick bunch of scripts to deal with this on my own, but it seems like I'm being contrarian to what hg wants me to be doing anyway and not learning The True Way. In Mercurial, as in most DVCS, the best practice is to have one branch per logical change. This works well for most users. If it doesn't work for you, just find a different solution. Nobody will judge you.
|
|
#
?
May 2, 2011 19:09
|
|
|
MononcQc posted:I'm getting tired enough with git evangelism that I might go to CVS NT out of spite. Or maybe Fossil. Fossil is neat. Until you realize noone on windows can work with you because the fossil devs are retarded about SSL.
|
|
#
?
May 2, 2011 19:33
|
|
|
This has probably been mentioned elsewhere in the thread, but I don't have any idea how to search for it. What are some ways (or the way) of handling dev-test/qa-prod environments in mercurial? First, a little background. I have thus far only been using mercurial in essentially a single developer environment. My company was purchased recently, and because of that we need to change some of our procedures to become SOx compliant. Included in this is the need to have a more formal set of dev-test-prod environments for our BI solution. Previously we just had a development folder on our reporting server, and when everything looked good the report would be copied to the "definitive" report solution (now littered with ~whatever and whatever.bak) and then deployed to the real location on the report server. Well, I figure if I'm going to have to rework the process anyway, why not throw in some sweet DVCS action while I'm at it. So, let's say my repository contains some SSRS projects. The project files, which I assume should be version controlled, have the deployment path in them. Also under version control are the data sources (assuming they aren't embedded in the reports) which contain things like connection strings. So the developer clones the "main" dev repository, makes some changes to a report file, pushes the changes back to the dev repository, and then deploys the report, which uses the dev database in its data sources, to the dev report server. Everything looks good, so then it's time to move the changes to qa. Whoever is in charge of such things pulls the changes from dev to the qa repository. Then what? The reports in qa are published to the qa server and look at the qa database (or whatever), so how do we make sure that stays true when we merge in the dev stuff? Likewise for qa to prod. Do we merge carefully? Do we merge and then re-edit all of the configurations and data sources before we commit? Do we change the configurations and whatnot before we even pull? Is there some magic that can be done with branches or queues or hooks or extensions? Am I even thinking correctly when it comes to having separate dev, qa, and prod repositories? I'm using mercurial because we all run Windows. Is this something that git could handle by reading my thoughts so I should just switch? Does TFS have a magic'd up solution? Am I just not thinking in portals?
|
|
#
?
May 3, 2011 19:54
|
|
|
Can someone recommend a workflow for a small team starting out with git? I know enough to get by, but only really as a single user. Most of the others have only used SVN. We'd also like to use Github as a central repository. This kind of branch model looks interesting and easy enough to follow, but like I say, I don't know enough to tell if it's actually terrible or not.
|
|
#
?
May 24, 2011 17:04
|
|
|
I don't see why you need to make it so complicated, forcing people to use unnatural constructs as rebasing and poo poo. Just write code, branch and merge, it's easy.
|
|
#
?
May 27, 2011 08:36
|
|
|
uXs posted:I don't see why you need to make it so complicated, forcing people to use unnatural constructs as rebasing and poo poo. Rebasing is incredibly useful as it makes merging easier. Instead of having to resolve ALL the conflicts all at once when merging, you can detach your branch and reattach it at a later commit, then resolve all the conflicts with that, then detach it again and reattach it an even later commit and repeat the process until your branch is based off master. Then you merge it in and have no conflicts.
|
|
#
?
May 27, 2011 08:56
|
|
|
Mithaldu posted:Rebasing is incredibly useful as it makes merging easier. Instead of having to resolve ALL the conflicts all at once when merging, you can detach your branch and reattach it at a later commit, then resolve all the conflicts with that, then detach it again and reattach it an even later commit and repeat the process until your branch is based off master. Then you merge it in and have no conflicts. Maybe you could just merge more often?
|
|
#
?
May 27, 2011 10:17
|
|
|
uXs posted:Maybe you could just merge more often? Yes, of course. I could constantly watch what's happening in the main branch and merge things into my branch, even if i don't know whether i'm happy with my changes as they are. Of course i'll lock the history of my branch in, because fixing issues in a feature branch with "revert blargh" commits is clearly superior to just going back and fixing bad commits. Of course i always have connectivity so there's never a time when i'm not able to stay on top of these things. Of course i'll also happily clutter up my commit history with hundreds of pointless merge commits. Or you know, i could just use an elegant and useful tool like rebase.
|
|
#
?
May 27, 2011 10:26
|
|
|
Sharrow posted:Can someone recommend a workflow for a small team starting out with git? I've heard good things about git-flow. This guy gives a nice concise example of it.
|
|
#
?
May 27, 2011 14:56
|
|
|
Mithaldu posted:Yes, of course. I could constantly watch what's happening in the main branch and merge things into my branch, even if i don't know whether i'm happy with my changes as they are. Of course i'll lock the history of my branch in, because fixing issues in a feature branch with "revert blargh" commits is clearly superior to just going back and fixing bad commits. Of course i always have connectivity so there's never a time when i'm not able to stay on top of these things. Of course i'll also happily clutter up my commit history with hundreds of pointless merge commits. But the merges would be what you're actually doing, so they're not pointless. Anyway, whatever. I just wanted to point out that going out of your way to make your development history completely linear isn't the only way to go. In development, branching happens all the time. It's not a crime to have your history show that.
|
|
#
?
May 27, 2011 15:37
|
|
|
uXs posted:But the merges would be what you're actually doing, so they're not pointless. uXs posted:I just wanted to point out that going out of your way to make your development history completely linear isn't the only way to go. In development, branching happens all the time. It's not a crime to have your history show that. Please keep in mind that a somewhat clean history is not just there for vanity, but helps the poor shlob who has to read your history to find out why you hosed with a certain piece of plumbing. Lastly, rebasing gives me control and granularity in my merging, without forcing me to continually think about it, or tieing me to a certain timeframe.
|
|
#
?
May 27, 2011 15:51
|
|
|
God drat git diff --stat @{yesterday}.. is awesome. Makes me feel like I've accomplished something after some major refactoring. Just thought I'd chime in with that.
Lysidas fucked around with this message at 21:01 on May 27, 2011 |
|
#
?
May 27, 2011 17:18
|
|
|
Mithaldu posted:[...] Yes, exactly. Not tidying your commits before pushing them somewhere public is like tweeting what you had for every meal; no one cares and it makes sifting through the noise for useful info harder. You can get away with the whole, "every
|
|
#
?
May 29, 2011 22:17
|
|
|
uXs posted:But the merges would be what you're actually doing, so they're not pointless. I posted this earlier in the thread, but it's relevant again so I'll repost it. Here are Linus's thoughts on rebasing and merging, as they relate to kernel development. Before reading that, I hadn't thought about the consequences that rebasing has on the testing you've done on your code. In some workflows, it might be more valuable to preserve the actual branching point than to keep a clean-looking history. Just some food for thought.
|
|
#
?
May 30, 2011 21:37
|
|
|
I accidentally entered "git config --global core.autocrlf = false" Now, when I try to enter "git config --global core.autocrlf false" I get: true error: More than one value for the key core.autocrlf: = What did I do? And how do I fix it?
|
|
#
?
Jun 1, 2011 05:15
|
|
|
Dooey posted:I accidentally entered "git config --global core.autocrlf = false" You probably now have a wonky line in your global config file. Whenever I do stuff like that I just open the config file and edit the bad line by hand: code:
|
|
#
?
Jun 1, 2011 06:04
|
|
|
Here's an odd question: Does anyone know if there are any human-readable descriptions of git graphing algorithms? I'm specifically trying to rebuild Tortoisegit's algorithm so i can use it in a web git viewer, but i'm getting stuck on a few edge cases where i cannot tell what it's basing its decisions on.
|
|
#
?
Jun 3, 2011 13:35
|
|
|
I don't want to veer off too much from this only being related to programming, but I would like to know if it's common for version control systems to be used other than just for programming. For a studio that has a mix of programmers and video editors and audio engineers, does it make sense for these things to be used? The reason I'm asking is because the studio I'm working at is looking for a better way to organized progress of projects and meeting deadlines. New video/audio edits here work much like code (like version control I think) where files are accessed from a host computer and keeping a log of what has changed is critical.
|
|
#
?
Jun 6, 2011 18:37
|
|
|
NOG posted:I don't want to veer off too much from this only being related to programming, but I would like to know if it's common for version control systems to be used other than just for programming. For a studio that has a mix of programmers and video editors and audio engineers, does it make sense for these things to be used? The reason I'm asking is because the studio I'm working at is looking for a better way to organized progress of projects and meeting deadlines. New video/audio edits here work much like code (like version control I think) where files are accessed from a host computer and keeping a log of what has changed is critical. As long as you don't start dumping huge binaries into the source repo you're fine.
|
|
#
?
Jun 6, 2011 18:39
|
|
|
Mithaldu posted:As long as you don't start dumping huge binaries into the source repo you're fine. Okay, this was exactly the problem I was thinking of. With video projects, they tend to run into the gigabytes, and I'm not sure exactly if their work flow will adapt to something like git. I'm just so unfamiliar it's hard for me to even imagine. I guess my best bet would be to just download a few and see how they work and they'll probably benefit my projects anyway. The thing that's different in my case is there are way more video editors than programmers.
|
|
#
?
Jun 6, 2011 19:03
|
|
|
NOG posted:Okay, this was exactly the problem I was thinking of. With video projects, they tend to run into the gigabytes, and I'm not sure exactly if their work flow will adapt to something like git. I'm just so unfamiliar it's hard for me to even imagine. I guess my best bet would be to just download a few and see how they work and they'll probably benefit my projects anyway. The thing that's different in my case is there are way more video editors than programmers. This is what perforce excels at handling large binary files. For comparison - I've worked on a depot that reached 2TB. Obviously at that size people don't sync to all of it only the parts they need.
|
|
#
?
Jun 6, 2011 19:25
|
|
|
ani47 posted:This is what perforce excels at handling large binary files. For comparison - I've worked on a depot that reached 2TB. Obviously at that size people don't sync to all of it only the parts they need. Thanks this looks amazing, but pricey. Not that I didn't expect that, but I don't think we want to spend that much money or even get something open source/free. Do you know of anything similar? Oh well, I guess solving problems like this come at a cost!
|
|
#
?
Jun 6, 2011 19:43
|
|
|
NOG posted:Thanks this looks amazing, but pricey. Not that I didn't expect that, but I don't think we want to spend that much money or even get something open source/free. Do you know of anything similar? Oh well, I guess solving problems like this come at a cost! Before you go whole hog, you can get a perforce evaluation license that supports 2 users to test it out and see how it works out for you.
|
|
#
?
Jun 6, 2011 20:36
|
|
|
ani47 posted:This is what perforce excels at handling large binary files. For comparison - I've worked on a depot that reached 2TB. Obviously at that size people don't sync to all of it only the parts they need. Having used P4 extensively at work, the main problems I've observed with it are: - it's pricey - it's amazingly slow - after using git or hg, it feels extremely awkward and dated That said, it does scale very well and handles binary files fine - it starts out slow but doesn't really get any slower as you add more stuff to it. It's also cross-platform, has both graphical and command line interfaces, and even has a nice Python API. It also has changelists, which don't really replace topic branches but are at least much more pleasant than what you get with, say, SVN. All in all it's not my favorite version control system, but if you need to control large numbers of large files you could do a lot worse.
|
|
#
?
Jun 6, 2011 23:20
|
|
|
|
| # ? May 10, 2024 14:58 |
|
|
NOG posted:I don't want to veer off too much from this only being related to programming, but I would like to know if it's common for version control systems to be used other than just for programming. For a studio that has a mix of programmers and video editors and audio engineers, does it make sense for these things to be used? The reason I'm asking is because the studio I'm working at is looking for a better way to organized progress of projects and meeting deadlines. New video/audio edits here work much like code (like version control I think) where files are accessed from a host computer and keeping a log of what has changed is critical. Can you separate the project files from the video data? My experience is with Avid Media Composer and as far as I can tell is that the project files more or less contain references to existing media (whether it's on a local disk or a network system like ISIS) and none of the media actually gets modified, but the client program stitches everything together, and new media (e.g. transitions) is stored alongside the existing media. I feel like versioning your media will end badly, but project files should be manageable.
|
|
#
?
Jun 7, 2011 04:53
|
|
