|
poo poo, the 4 people covering the story didn't pick that up.
|
#
¿
Apr 2, 2014 17:08
|
|
|
|
| # ¿ May 16, 2024 07:47 |
|
|
^^^ Sourcetree actually does pretty well on that front. FWIW, the few guys we have doing command line commits tend to commit the most extraneous junk. Whereas the guys doing gui commits tend to keep things clean. hg add -a is a wonder drug it seems.
|
|
#
¿
Jul 2, 2014 20:21
|
|
|
The kicker for us has typically been CI -- we really want everything to get there in one package and not have to figure out ways to stitch multiple repos together. One thing we have started doing is doing subrepos for things with big binaries in it. Typically we don't care so much for the tracking data on said binary, only that it can get pulled in with the project in one fell swoop. The project we do care about history. So we can keep the binaries separate and avoid risks of making a repository to big for hosts to deal with / too large to download / what have you. If you pave the files and it doubles the size of the repo you can always choose to just integrate a new subrepo that is clean. It has saved a few things and we've only had this in place for a year or so.
|
|
#
¿
Aug 1, 2014 18:22
|
|
|
caiman posted:If I keep my css out of my repo, will I need to manually transfer the .css files every time I deploy? Seems to defeat the purpose of Beanstalk's automation. Is there a better solution? The best way is to get grunt out on the server then have a "build production" config that compiles stuff for production. Compiled artifacts never hit any repo.
|
|
#
¿
Jun 10, 2015 18:51
|
|
|
I had some run ins with it back in the day -- it is definitely archaic but the description of "vss that works" is pretty accurate and it is certainly better than nothing and was a valid technical decision at the time most likely. That said, I'd be a bit worried why they haven't re-visited the decision, it is a red flag there is lots of other archaic poo poo there. Like VB6 or something.
|
|
#
¿
Jun 11, 2015 06:18
|
|
|
revmoo posted:I'm doing a writeup comparing Git to SVN. Can someone please confirm that SVN does in fact discard commit history when merging branches? That's been my conclusion but I want to be sure of it before I go running my mouth about it. No SVN scientist but I had a solid decade of using and and administering it. If I'm understanding your question correctly I'd say the answer is yes and no. SVN merges don't work like git pull requests, more like a branch merge. You don't get the commits imported like a pull request (sans squashing) but the commits would still exist in the branch one did the work in. To some extent this is wrapped up in deep differences between DCVS and non distributed CVS.
|
|
#
¿
Oct 16, 2015 15:50
|
|
|
revmoo posted:Crazy poo poo, so you either keep around hundreds/thousands of feature branches so you can keep track of your commit history, or you say "eh, screw it" and merge/delete as you go. So basically your commit history is just a list of dates branches were merged in. To me, branching is an absolute requirement. Every ticket/task gets a branch, you do the work, test it, and merge in. But if you are using proper branching hygiene, then it means you get no commit history other than who/when a branch was merged. It almost seems pointless to use a VCS at that point if you're not tracking commit history. We often have feature branches that will stay open for months with hundreds, if not thousands of commits, and I couldn't fathom throwing all of that history away once the feature is complete. I don't find it that crazy myself -- I *like* to have that granular level of primary source history around if I need it. You can filter branches pretty effectively when looking at SVN, and keep in mind you aren't carrying the entire repo history with you so this works a bit better in practice. SVN is a very, very different model from perhaps a different era. If you want it to behave like git it sucks, just ask linus. On the flip side when you want git to behave like SVN that can also suck. Go figure.
|
|
#
¿
Oct 19, 2015 15:01
|
|
|
The other thing one can do in SVN you can't quite do directly in git is check out parts of trees. We've got a few opsy things we run that way with SVN that would never work with git without a bit more doing. If your version control is simple enough that you've got an effectively linear commit system with minimal branching than just about any modernish CVS system will work.
|
|
#
¿
Oct 21, 2015 22:19
|
|
|
|
| # ¿ May 16, 2024 07:47 |
|
|
I've got 2 large web farms running just about every stack imaginable. Almost enough skilled humans and more than enough monitoring services to look after and maintain these things properly. We still host all of our sources in bitbucket, it just isn't worth the care and feeding.
|
|
#
¿
Nov 11, 2015 16:50
|
|