|
Don Music posted:So, I'm a Software Engineering student, and for my Agile Software Development unit this semester we have to take an existing project, made in Java with servlets and built by Ant and create an add-on for it. Your project members are smoking crack if they want to use TFS for a semester project doing java. It's one of the all-time dumbest ideas I've ever heard.
|
#
?
Jul 26, 2013 12:09
|
|
|
|
| # ? May 12, 2024 23:22 |
|
|
Regardless of your current strategy, I'm going to recommend that you use or at least try to use Jenkins. You can use it to a minimal level to ensure that your code always compiles and the tests always pass, but you can do a lot more with it.
|
|
#
?
Jul 26, 2013 12:39
|
|
|
There's so much TFS hate in this thread. Using the cloud-hosted TFS Service with Git is a great idea. TFS has really rich, powerful project management tools. For the record, I've had clients who use TFS for Java applications before, and they loved it.
|
|
#
?
Jul 26, 2013 12:48
|
|
|
I admit the modern version is certainly markedly better than what came before and that the current iteration might even be a viable SCM platform, I have still yet to see anyone who isn't: a) a microsoft employee or b) a TFS consultant or c) a non-coding manager / accountant express any positive sentiment about TFS.
|
|
#
?
Jul 26, 2013 18:27
|
|
|
wwb posted:I admit the modern version is certainly markedly better than what came before and that the current iteration might even be a viable SCM platform, I have still yet to see anyone who isn't: I liked it before I consulted in it. Developers usually don't have much to say about it because when it's working properly, it's pretty unobtrusive, just like any good source control should be. It has great tools for project management/reporting, which is why group C likes it. [edit] And it's definitely been a viable source control platform for a long time. I started using TFS2008 in 2009 or so. I can't speak to VSTS2005, that seems like it was a clusterfuck. New Yorp New Yorp fucked around with this message at 18:32 on Jul 26, 2013 |
|
#
?
Jul 26, 2013 18:29
|
|
|
Ithaqua posted:I liked it before I consulted in it. Developers usually don't have much to say about it because when it's working properly, it's pretty unobtrusive, just like any good source control should be. It has great tools for project management/reporting, which is why group C likes it. TFS is good at some things, but it completely defeats the point if you're working in Java. The cool parts about TFS like the msbuild integration, Visual Studio integration, etc all are not going to work with a Java toolset. If he were doing like a C# app and he was tooled using visual studio, it wouldn't be such a bad idea.
|
|
#
?
Jul 26, 2013 19:45
|
|
|
hieronymus posted:TFS is good at some things, but it completely defeats the point if you're working in Java. The cool parts about TFS like the msbuild integration, Visual Studio integration, etc all are not going to work with a Java toolset. If he were doing like a C# app and he was tooled using visual studio, it wouldn't be such a bad idea. There's an Eclipse plugin for TFS that gives similar IDE integration. Build is a bit trickier, there are resources to get it working. I'm not saying that TFS is the best choice for source control for Java applications, but Microsoft is aggressively pushing it out into the non-Microsoft dev world (see: Git fully integrated in TFS2013). It's a viable choice, especially in this case.
|
|
#
?
Jul 26, 2013 20:37
|
|
|
Ithaqua posted:There's an Eclipse plugin for TFS that gives similar IDE integration. Build is a bit trickier, there are resources to get it working. This was the plan, to use TFS with Eclipse, especially seeing as it now supports Git etc. Thanks for the opinions, folks. Still not sure on what I'll do though. Hopefully we can figure out how to use Jenkins, seems like a pretty nifty tool.
|
|
#
?
Jul 27, 2013 05:30
|
|
|
Hello my TFS-hating or TFS-ambivalent friends! Brian Keller at Microsoft just released a VS/TFS2013 ALM VM. I'm playing with the native Git support right now and what I'm seeing is definitely encouraging. If you're a .NET shop and you've decided not to use TFS because you don't like CVCS, take a look at TFS2013. The Git tools are pretty rad, and it works flawlessly with build and deployment (with InRelease).
|
|
#
?
Aug 3, 2013 01:35
|
|
|
git question. I have a git repo that I push to both github + heroku. However, my app needs a "secret key" that I want to be pushed to heroku, but not github (as the app is open source, but I still need a shared secret between the client and server apps". What is the best way to handle this?
|
|
#
?
Aug 3, 2013 19:32
|
|
|
mmm11105 posted:git question. Use heroku config vars to set environment variables on your Heroku dynos (and then set environment variables the normal way on your machine for development). https://devcenter.heroku.com/articles/config-vars
|
|
#
?
Aug 3, 2013 19:51
|
|
|
My company uses phabricator for code reviews and issue tracking, which is currently hated by everyone except the guy who set it up. Is there something better that supports a squash/rebase type of workflow? We use git and we're pretty cool with that. We have about 10 devs, mostly on linux or osx, and it needs to be self-hosted for legal reasons.
|
|
#
?
Aug 3, 2013 20:40
|
|
|
evensevenone posted:My company uses phabricator for code reviews and issue tracking, which is currently hated by everyone except the guy who set it up. Is there something better that supports a squash/rebase type of workflow? We use git and we're pretty cool with that. For self-hosting Git I would suggest a straight Gitolite or Gitlab installation, or to buy something like Github or Atlassian Stash.
|
|
#
?
Aug 3, 2013 21:34
|
|
|
We use gitolite for the actual hosting and that's not a problem, it's more of a code-review and task/bug tracking system that we're looking for. I wanted github but it seems like its really based around having a single maintainer that merges pull requests. Whereas we like to just individually rebase onto master and push to our origin.
|
|
#
?
Aug 4, 2013 02:48
|
|
|
I use set up an account at https://www.unfuddle.com downloaded TortoiseSVN, VisualSVN (Visual Studio plugin), and had my code online within 10 minutes with no troubles. I don't want to use GitHub because I want to keep this private. Pretty sweet stuff that I can recommend so far.wwb posted:I admit the modern version is certainly markedly better than what came before and that the current iteration might even be a viable SCM platform, I have still yet to see anyone who isn't: That being said, I'd never use it at home, without Visual Studio, or hosted, but it doesn't bother me at work. I don't really give much for its project management tools. Work items/bugs/tasks are unnecessarily complex, have way too many fields, and the UI doesn't give a very good overview. I don't give a poo poo how our project managers organize stuff in areas, paths, child items, requirements and the like... just gimme the tasks!
|
|
#
?
Aug 4, 2013 19:41
|
|
|
I've been tasked with giving a presentation on integrating Eclipse with Git + TFS, so I have a few Git questions for people that have a ton more experience actually using Git day-to-day; my experience with Git is limited to Github. The "Eclipse" part is basically irrelevant to my questions; I set up EGit and my demo is basically going to be source controlling "hello world" in Java; the focus isn't on the language, but on Git and the IDE. EGit is pretty straightforward so no worries there. So, I intend to demo two ways of using Git + TFS:
Given that with TFS2012, the first step is to "clone" the TFS source tree into a local repo (and then use that local repo to sync back and forth to TFS), what's the best practice regarding that? Should I clone my local repo again and treat the TFS-syncing repo as a "remote" repository, or just develop directly against that repo? Also, what's the generally accepted practice regarding branching? I know Git is branch-happy because it's cheap, but is it frowned upon to clone a repo and then commit changes directly? When should I merge versus rebase? I'm not super clear on that, although I've admittedly not done a lot of reading on rebasing.
|
|
#
?
Aug 7, 2013 03:58
|
|
|
Ithaqua posted:Also, what's the generally accepted practice regarding branching? I know Git is branch-happy because it's cheap, but is it frowned upon to clone a repo and then commit changes directly? When should I merge versus rebase? I'm not super clear on that, although I've admittedly not done a lot of reading on rebasing. "master" is suppose to be the stable version/main branch of whatever project you're working on. Committing directly into the main branch is akin to saying my code is perfect, no one needs to review the code I worked on. You should only be committing directly into the main branch when it is a minor thing that would not affect anyone at all like a typo or a one-liner bugfix (wrong variable name or using && instead of ||), but even then at where I work I have someone come over to take a look. Obviously this isn't needed if you're working on your own project, but branching is good practice and gives you liberty to really mess things up and be able to revert back to a nice stable version if it doesn't work out. You can revert just as easily on the main branch but then you have to check where the last stable version was and then git reset --hard to it and pray you didn't forget anything (I think a soft reset might work but you may get loose files from the commits you reverted). Branching puts your mind at ease because 1) you can restore the branch in case something cool was left there and 2) you don't have to scan and make sure you're reverting to the correct commit, just git checkout master, git branch -D branch_to_delete and you're back on your stable version. Think of rebase as being able to modify your current branch's history. If you create a branch A' off of A, as long as A' does not get pushed into a shared location (such as a remote repo or github) you should be using rebase to add new commits from A into A'. This keeps your history clean and your commits from A' at the top of the log. If I do any kind of merge functions locally it is usually because I am merging different commits from branches A' and A" into A to see how well the changes in A' and A" work together. Generally the practice is to branch off stable, make commits as often as possible to your branch, then when you are cleaning up to merge into your stable you do a git rebase -i <sha1 of stable>^ (there is a carrot at the end). This brings up your editor along with all the commits you've made in the branch. From there you can squash, move commits, edit commit messages, etc. Once I clean everything in my branch, I push the branch to GitHub and make a PR.
|
|
#
?
Aug 7, 2013 06:59
|
|
|
Thermopyle posted:A certain type of person doesn't view coding outside of their job as "work". This type of person comes with a set of attributes that many employers would like. this is only really a thing for the first 5, 10 years of most engineers careers. after a while, you stop doing the same thing for your hobby as you do for your 9-5. "show me the code you write for fun" is really not a reasonable question for senior engineers imo
|
|
#
?
Aug 8, 2013 06:10
|
|
|
rotor posted:this is only really a thing for the first 5, 10 years of most engineers careers. after a while, you stop doing the same thing for your hobby as you do for your 9-5. Yep, I wouldn't disagree, and I would note that this is complementary to my point.
|
|
#
?
Aug 8, 2013 07:17
|
|
|
on topic: git still sucks, svn still rules, suck it linus
|
|
#
?
Aug 8, 2013 07:23
|
|
|
TortoiseSVN finally lets me separately commit individual changes within a file, hooray.
|
|
#
?
Aug 8, 2013 08:52
|
|
|
rotor posted:on topic: git still sucks, svn still rules, suck it linus I have come around to agree with the third clause of this, he's become a megaprick on mailing lists
|
|
#
?
Aug 8, 2013 13:35
|
|
|
lol if you think that's recent, it's always been that way but now you have more vocal crybabies posting on their tumblers and what have you. drat kids  Also SVN sucks compared to HG.
|
|
#
?
Aug 8, 2013 15:15
|
|
|
By recently I mean the last five years or so. He wasn't nearly as bile-filled when he was arguing with Tannenbaum in Ye Olden Dayes as he was when he got into the argument that led to Alan Cox quitting the first time and that was what, four years ago?
|
|
#
?
Aug 8, 2013 16:01
|
|
|
Is there a good SVN client for mac?
|
|
#
?
Aug 8, 2013 19:29
|
|
|
I've been using TortoiseSVN on Windows to manage some small personal projects. I'm a baby-level user, but it's working well enough. I want to get better acquainted with the command-line blood and guts of SVN, so I started reading http://svnbook.red-bean.com/. This book seems good and comprehensive and all, and it's improved my operation of TortoiseSVN, but I still haven't gotten to 'the point' - svn isn't in my windows path, so the command line perspective I'm looking to learn isn't available to me. Can I go ahead and install the windows subversion client from http://sourceforge.net/projects/win32svn/ , or will that conflict with Tortoise's install somehow? Does Tortoise already have the command line stuff somewhere 'underneath', and can I just add the svn command to my path and go along my merry way?
|
|
#
?
Aug 8, 2013 21:35
|
|
|
You should be able to just add the TortoiseSVN\bin directory to your PATH.
|
|
#
?
Aug 8, 2013 23:09
|
|
|
HappyHippo posted:Is there a good SVN client for mac? the one on the command line works fine  there's a program called Versions which I hear is good but it costs money
|
|
#
?
Aug 9, 2013 03:53
|
|
|
Newf posted:I've been using TortoiseSVN on Windows to manage some small personal projects. I'm a baby-level user, but it's working well enough. install cygwin
|
|
#
?
Aug 9, 2013 03:53
|
|
|
rotor posted:install cygwin Unless there is some missing functionality that I am unaware of, Win32SVN is a more lightweight option for a Windows command line SVN. College Ruled fucked around with this message at 13:02 on Aug 9, 2013 |
|
#
?
Aug 9, 2013 11:59
|
|
|
Word, so I have a dev VM, staging server and live server with a git repo on all, synced by an origin repo. On the dev VM, is just whatever I happen to be working on, usually a branch. I create new branches from master, do the work, then check out that branch on the staging server for clients to approve. Once approved, I merge the branch into master and create a tag from master. On the live server, I am always pointing to a tag. But what confuses me is, when I have a new tag to deploy on the live server, I have to checkout master, pull the new commits, pull the new tag, then check out the tag. Ideally, I don't want to have to checkout master, pull, *then* check out the tag. I just want to hop from one tag to the next. Is this possible? I imagine I need to pull all the new commits before I can check out a tag that points to these new commits. Hope this makes sense.
|
|
#
?
Aug 9, 2013 15:41
|
|
|
Why would you need to checkout master before fetching?
|
|
#
?
Aug 9, 2013 19:00
|
|
|
Right, so if I fetched the commits and fetched the tags, I could then just safely switch to the new tag? But the commits won't be merged into master like a pull would do... that's OK?
|
|
#
?
Aug 9, 2013 20:41
|
|
|
If your live server isn't going to be pushing changes back up to a repository (it shouldn't) then it doesn't matter what your local branching looks like. Just use 'git fetch --all', 'git fetch --tags', then 'git checkout [tag]'. When running that last command, your HEAD won't point to a branch - but that shouldn't really matter if you're not making local modifications. EDIT: I should note that I much prefer to have a branch per stable deployment and have those branches updated when a new deployment goes out. My 'master' branch is equivalent to what is on production, my 'staging' branch is equivalent to what is on staging, the 'dev' branch is what our changes are committed to in the interim, and feature branches get merged into dev. We just use tags for historical versioning. This setup makes it very easy to reason about what code is where. Bognar fucked around with this message at 21:42 on Aug 9, 2013 |
|
#
?
Aug 9, 2013 21:38
|
|
|
Yep, the staging and live servers have SSH key auth so they can't push anything. So as long as it has the commits, the head can just be detached to whatever commit I set my tag to, regardless of merging, OK, makes sense.
|
|
#
?
Aug 9, 2013 21:48
|
|
|
College Ruled posted:Unless there is some missing functionality that I am unaware of, Win32SVN is a more lightweight option for a Windows command line SVN. neat!
|
|
#
?
Aug 10, 2013 07:47
|
|
|
Question on git. I have a Repository A, lets call it SharedLibrary and another Repository B, lets call it Project. I'm in a confusing situation where I would like Project to use some of the libraries from SharedLibrary, but I want to keep SharedLibrary seperate from Project. I was looking into submodules and it initially seemed like the way to go, but then I've read on how the submodule feature is not-so-great after all? Is there a better way to approach this? Currently I'm running into the problem of NuGet not playing nice where the SharedLibrary projects in my Project solution are missing references to NuGet libraries. Any ideas on how to get around this (both the Project solution and SharedLibrary solution are using NuGet)? And as a side question which is tangentially related, with submodules if I want to make changes to SharedLibrary from the Project solution, do I just (in git) cd into the SharedLibrary submodule folder and commit / push / pull as if it was my actual SharedLibrary working directory (which would be a couple levels up and side-by-side the Project working directory)? Then the next time I load up the SharedLibrary solution I just need to pull the latest to get the changes I've made in Project?
|
|
#
?
Aug 13, 2013 20:57
|
|
|
Mr. Crow posted:Question on git. I would avoid that kind of setup entirely, keep my projects in separate repositories and just reference the needed assemblies manually. Since you mentioned NuGet, I'm assuming you're in .NET so this isn't really hard. The problem I have with your setup is that changes in one solution might cause breaking changes in another solution which can be extremely confusing if you're not expecting it. It's much better to rely on a stable, built assembly for each project so you can be sure of when to expect potential breaking changes. Sure, it means an extra copy step when you update the shared modules, but I think that's a small price to pay for knowing that your changes won't break code in entirely different project.
|
|
#
?
Aug 13, 2013 22:12
|
|
|
Bognar posted:The problem I have with your setup is that changes in one solution might cause breaking changes in another solution which can be extremely confusing if you're not expecting it. It's much better to rely on a stable, built assembly for each project so you can be sure of when to expect potential breaking changes. Sure, it means an extra copy step when you update the shared modules, but I think that's a small price to pay for knowing that your changes won't break code in entirely different project. submodules (and subtrees) don't magically change when the upstream project changes, so that's not an issue.
|
|
#
?
Aug 13, 2013 22:26
|
|
|
|
| # ? May 12, 2024 23:22 |
|
|
To partially answer one of my questions, though perhaps a better approach is needed (I'll deal with it for now since it's just a personal project); you can open the submodule solution which will cause nuget to pull the packages into the correct directory (the submodules) so the submodule projects can find the references they need. And with .gitignore ignoring the packages directory, git doesn't complain about the submodule being dirty.
|
|
#
?
Aug 15, 2013 21:10
|
|