|
Marsol0 posted:I'm going to pitch Atlassian's Stash to my company for git repository management. Is there any reason that this might be a bad idea? They want behind-firewall repo mangement (paranoid about theft or something I don't know and I'm not going to fight it). And since we're using Jira I figured the integration would be nice to have. It's also cheaper than Github Enterprise. Have you tossed it up on a staging server yet? The promised integration between Jira/Stash and Jira/Bamboo is... less impressive than advertised. They're all still good products in their own right, don't get me wrong, but if you're expecting some amazing level of integration, definitely throw the trial on a VM or spare machine before pitching it.
|
#
?
Sep 23, 2013 21:39
|
|
|
|
| # ? May 12, 2024 15:14 |
|
|
Molten Llama posted:Have you tossed it up on a staging server yet? The promised integration between Jira/Stash and Jira/Bamboo is... less impressive than advertised. I haven't setup the trial server yet, I'm just trying to avoid unnecessary work if the general opinion about Atlassian Stash is garbage and not to bother. Just to save myself some headache, is all. Volmarias posted:This isn't a particularly strange concept. The company wants control over their own IP, and they're concerned about letting a 3rd party manage it. They'd likely want everyone in GitHub who potentially has access to your account to sign NDAs, and to sign a contract where GitHub would assume liability in the event of a breach where your codebase was leaked. I doubt GitHub would go for that, so there you are. I understand the reasoning, I just mention that part in case someone wanted to reply with "Use github! Use bitbucket!"
|
|
#
?
Sep 23, 2013 21:59
|
|
|
I use rhodecode for mercurial, it also works for git but I can't comment on that
|
|
#
?
Sep 24, 2013 02:27
|
|
|
Marsol0 posted:I haven't setup the trial server yet, I'm just trying to avoid unnecessary work if the general opinion about Atlassian Stash is garbage and not to bother. Just to save myself some headache, is all. Related to this, we've been approached a larger company to help streamline their offshoring operations with Indian developers. One of their requirements is something Git-like, but with the ability to restrict by IP and/or limit to VPN access. However, they still want it to be cloud-based and not self-hosted (why if you're limiting by IP I'm not sure). I've looked up Beanstalk, which seems like kind of the most popular provider for this kind of thing, but thought I'd pick your guys' brain for comparable services/cheaper hacks to get the same thing.
|
|
#
?
Sep 24, 2013 20:16
|
|
|
I think I've stumbled into a situation where I think I should apply some git/subversion bridge with git-svn. I haven't done this before so I wanted to go over this and figure out if it's even valid. We've fallen into a subversion repository that basically used as a release mechanism. You commit your code there, and end users end up just pulling and running the scripts out of it. This doesn't leave any room for intermediate commits, or merging multiple user's work into a single release. Somebody could just come along in the middle, pull out the new, intermediate commits, and gets screwed. I would rather torpedo that entire methodology, but politics prevail. Alternately I want to just use branches to hide all the changes until we're ready to deploy in the trunk, but it looks like politics are prevailing there too. So to insulate ourselves from this, I was hoping to create a git repository to represent our branches, with the subversion repository as one remote, a staging remote for testing the mass of changes, and development remote for our day-to-day work. I got the impression this is quite possible with git-svn, but I wanted to verify it. We normally host git repositories from a host we don't control, so I don't know how we'd set up a bridge like that. Would every user that could pull or push to/from subversion side have to set up something special?
|
|
#
?
Sep 24, 2013 20:37
|
|
|
Marsol0 posted:I'm going to pitch Atlassian's Stash to my company for git repository management. Is there any reason that this might be a bad idea? They want behind-firewall repo mangement (paranoid about theft or something I don't know and I'm not going to fight it). And since we're using Jira I figured the integration would be nice to have. It's also cheaper than Github Enterprise. http://gitlab.org/ dude
|
|
#
?
Sep 28, 2013 05:57
|
|
|
its not exactly github but it's pretty close. if you must use git, i dont see why you wouldn't use gitlab or something like it, it's basically the only thing that makes it marginally worthwhile.
|
|
#
?
Sep 28, 2013 05:59
|
|
|
rotor posted:its not exactly github but it's pretty close. lol, no. It's one of those clones that tries to emulate GitHub as it was three years ago, since it has no independent vision about its featureset or its design.
|
|
#
?
Sep 28, 2013 12:12
|
|
|
Suspicious Dish posted:lol, no. It's one of those clones that tries to emulate GitHub as it was three years ago, since it has no independent vision about its featureset or its design. Yeah, as far as I've been able to find, there's nothing even remotely close to Github nowadays. Not that I've trialed every possible result that shows up on related Google searches, but I've tried out a decent number of them.
|
|
#
?
Sep 28, 2013 16:23
|
|
|
Suspicious Dish posted:lol, no. It's one of those clones that tries to emulate GitHub as it was three years ago, since it has no independent vision about its featureset or its design. yeah i dont really know what the distinction here is, but it's an in-house hostable system that enables a github-like workflow where pull requests are the mechanism for code reviews and that's really all i care about. I've never liked the Altassian stuff as it never wants to play nicely with non-altassian products. edit: also it's not 50k/yr, that is an important feature.
|
|
#
?
Sep 29, 2013 19:01
|
|
|
Has anyone had experience using TFS command-line ("Team Explorer Everywhere") on OS X ? I need to make some changes in a TFS repo (or whatever they are called) and was wondering if installing that and using my normal editor is a viable option versus running a WindowsVM and using VisualStudio.
|
|
#
?
Sep 30, 2013 13:52
|
|
|
This is going to turn into a long'ish post and curious on any thoughts, but an immediate question I have, do any of the git GUI (or mercurial) clients support aliases? Now the scenario. If anyone reads it and comments you're a trooper and I appreciate it  So at my job, we use SVN and essentially have a single master branch that everything is done on. Typically we will create a branch for a task and leave the master alone, and then when the branch is ready to be code reviewed, check it into the master branch, where it gets reviewed and defects addressed etc. We have a CIS that builds and runs tests daily and after every commit. So we could (and regularly did... multiple times a day) released code into the master branch that nobody had even reviewed yet, much less any sort of guarantee the code compiled and/or the unit tests passed.  I know. I made a comment / question about it shortly after I started, got one of those 'yea it's kind of hosed up and should be addressed, but it works and hasn't caused any issues so we haven't bothered' responses; and since I was new and it had since not cause any major issues ignored it. Along with this me and another guy did some research and proposal to move from SVN to git, and we all decided that it would be worthwhile, but not until the end of the year / this major release, since moving to git presents a large learning curve, probably not smart to do it right now etc. So again, it got pushed on the backside and ignored.A couple weeks ago, the fact that we had a single branch for everything eventually bit us in the rear end, details don't matter; but I made a huge stink about the whole idiotic process, made arguments, bosses recognized the process was screwed up and so now I'm essentially coming up with a proposal to revamp our workflow and likely make the switch to DVCS. My initial thought was just something super basic e.g. git flow or something similar. Basically devs work on a feature branch, commit to a dev branch, we have a testing team writing automated tests for everything that is essentially a sprint behind us so have them updating the integration tests and then pushing to a beta branch, and then finally a master branch. The thought was we could set up pre-tested commits using the CI server to make sure devs aren't committing anything to dev that doesn't build and pass unit tests. The testing team would then update the integration tests and push whatever version of dev to beta, assuming all the unit tests and integration tests pass. Then periodically, when we want to release, push things into the master branch. There are two problems with this, we don't currently do any sort of code-freezing process to resolve bugs, so the point was made (and it's valid) we could end up in a scenario where someone is always checking in new code that prevents anything ever being pushed to the beta branch. The second is we constantly release engineering/development releases every 2 weeks to show off new features and get feedback from users, so we can't use the beta branch which is at least 4 weeks behind. Basically we're very 'feature' driven and not the typical 'release' driven model most software companies use. This led me to the Branch-Per-Feature (or The Dymitruk Model) workflows, which sounds exactly like what we want and need. So I've been doing a lot of research on it and coming up with the proposal, but there are basically two major concerns I have. One, this might be too much too fast for several/most of our developers; going from SVN -> git alone is quite a learning curve, then further complicating things going from a 'derp derp one branch' to 'multiple branches in this new VCS with some very specific workflow requirements'. Two, we have to be able to allow people to use a GUI, a lot of people don't like command line (I used to be one of them, but working with git I've learned that it aint so bad v  v). See my primary question at the top.Are we destined to crash and burn if we try to do all this at once? Would I be better off proposing all of this, with the caveat we move to DVCS now with a basic 'feature branchs per dev, review the branch then pre-test commit to the main branch' workflow and revisit doing something with more safeguards when people get used to DVCS?
|
|
#
?
Oct 1, 2013 02:05
|
|
|
Our house has been using Clearcase up to now (I know  ). Fortunately, with the Solaris->Linux port/upgrade we're working on we've got a chance to change it up, and SVN seems to be the pending winner right now. There anywhere I can read up on how the two differ and what bad habits I'm gonna have to unlearn if any, or should I just start reading the Red Bean book mentioned in the OP?(I basically got thrown to the dogs on this source control stuff by making the cardinal mistake of volunteering when a coworker left, not knowing a drat thing about the subject. So I probably learned a LOT of bad habits...) Ciaphas fucked around with this message at 02:25 on Oct 1, 2013 |
|
#
?
Oct 1, 2013 02:21
|
|
|
you can do the branch per feature thing in svn too. the merges can potentially be uglier, but you can minimize the pain by merging often and trying to keep concurrent work in the same areas to a minimum. the lack of ship dates or code freezes is an institutional issue that has nothing to do with the vcs. Typically the way it goes is you hit whatever milestone you want (release date, feature set complete, 2 week engineering release scheduled, whatever) and branch. That branch gets sent to QA or whatever and the devs move on with their lives and continue working on feature branches and merging into the trunk. If there's things that get that release kicked back from QA, then you either fix it on the branch and merge those fixes in, or branch again from the trunk, whichever seems appropriate.
|
|
#
?
Oct 1, 2013 05:15
|
|
|
At my work we do more or less what you describe. We use git-flow (which is a nice addition to git) and work on our own feature branches for bigger features or directly in the develop branch for minor things like spelling mistakes or things you think will be done quickly (and if you're wrong just continue in a feature branch and reset develop). Every check-in to any[1] of the branches is build and tested and the result is posted in the IRC channel all of us devs are in. The result message contains useful info like the commit hash and a link to the git web interface which will bring you to the diff. You did not tell me how many developers there are. There's six of us at my work so this might not work as well for bigger teams (f.e. too many commits in the IRC channel so people start ignoring it). As to git-flow, I would introduce it and the work flow right along with git. It's an improvement using git from scratch and frankensteining your own work flow. [1] there are some exceptions I think
|
|
#
?
Oct 1, 2013 08:13
|
|
|
I would agree with rotor(!) that git is not a silver bullet for many of the problems you describe. Code reviews slip if they're not extremely easy to do. Do you have a review portal set up? Any convention on how to share the review work? Is someone with authority confronting devs who break the build? Git won't do any of these; they're mainly social problems. Git won't QA your software either. If you're stuck in the "just be careful" approach to QA, don't expect your quality situation to improve until you move out of it to some kind of release vetting process. However, git-svn is available if you want to try it out as a solution for the problem of devs committing too soon or being afraid to branch. No changes required to your source control back-end and you can stop using it at any time. Gazpacho fucked around with this message at 08:38 on Oct 1, 2013 |
|
#
?
Oct 1, 2013 08:32
|
|
|
One thing that does help feature freeze and such is continuious deployment -- if you are constantly deploying small changes then the fear factor goes way down. If this is possible depends on the nature of the business.
|
|
#
?
Oct 1, 2013 14:11
|
|
|
rotor posted:you can do the branch per feature thing in svn too. the merges can potentially be uglier, but you can minimize the pain by merging often and trying to keep concurrent work in the same areas to a minimum. My three biggest gripes with SVN are that it's slower (even with SSH) than git on my SSD, merging is a semi-regular issue (team is ~20) which DVCS will help alleviate (not solve completely obviously), and there is no way to stash changes / branches are second-rate. Don't get me wrong there is nothing wrong with SVN, I've made the point clear to the higher-ups. It's more of a 'what do we gain by moving to DVCS' issue than anything. rotor posted:the lack of ship dates or code freezes is an institutional issue that has nothing to do with the vcs. Typically the way it goes is you hit whatever milestone you want (release date, feature set complete, 2 week engineering release scheduled, whatever) and branch. That branch gets sent to QA or whatever and the devs move on with their lives and continue working on feature branches and merging into the trunk. If there's things that get that release kicked back from QA, then you either fix it on the branch and merge those fixes in, or branch again from the trunk, whichever seems appropriate. I don't really see it as an issue at all. We have a very long release schedule where we do the typical thing and 'officially' release the product, but it's on a year - two year cycle. Between that we essentially are in bed with the users and developing the product based on feedback (and whatever else), so we're constantly releasing new features and getting feedback on them. I hate to use the word because its very cliche, but we have a very agile process. aerique posted:At my work we do more or less what you describe. We use git-flow (which is a nice addition to git) and work on our own feature branches for bigger features or directly in the develop branch for minor things like spelling mistakes or things you think will be done quickly (and if you're wrong just continue in a feature branch and reset develop). ~20+ people. I like the IRC idea, we have been using google chat to communicate but since they moved to the hangouts thing nobody likes it, I pitched IRC once or twice but never got a solid answer; we used it at my old job and I loved it. I think it would be perfect if we could get rid of spam build server emails and dump the output into an IRC server, one more reason to set one up I guess. @git-flow, I don't think it will really work for us based on my original comments / the observations that were made to me. Gazpacho posted:I would agree with rotor(!) that git is not a silver bullet for many of the problems you describe. Code reviews slip if they're not extremely easy to do. Do you have a review portal set up? Any convention on how to share the review work? Is someone with authority confronting devs who break the build? Git won't do any of these; they're mainly social problems. Git won't QA your software either. If you're stuck in the "just be careful" approach to QA, don't expect your quality situation to improve until you move out of it to some kind of release vetting process. I think you misunderstood? Code reviews are being done (you'd get in huge trouble if we somehow didn't review a task), the problem was they were being done on the master branch after-the-fact, e.g. I could put or break whatever I want in the master and no one would know until someone got around to reviewing it, which could be up to the next day. I'm aware of git-svn, I've used it in the past but haven't really been using it on this team... I'm not sure why, I just haven't. Think I remember it being kind of finicky and destroying any sort of SVN log history or something, which is why I didn't use it now. But yea, the more I think about it the more I think I'd be overcomplicating things. I remember reading this a while ago but just remembered it and honestly it's very similar to what we do now. If nothing else it would be a good interim solution, fairly similar to what we do now and with using pre-tested commits till we eventually move to something more robust (if the need arises).
|
|
#
?
Oct 1, 2013 16:10
|
|
|
Mr. Crow posted:I hate to use the word because its very cliche, but we have a very agile process. You shouldn't use the term Agile if you're not actually doing Agile development.
|
|
#
?
Oct 1, 2013 16:39
|
|
|
Mr. Crow posted:I think you misunderstood? Code reviews are being done (you'd get in huge trouble if we somehow didn't review a task), the problem was they were being done on the master branch after-the-fact, e.g. I could put or break whatever I want in the master and no one would know until someone got around to reviewing it, which could be up to the next day.
|
|
#
?
Oct 1, 2013 16:47
|
|
|
Mr. Crow posted:I think you misunderstood? Code reviews are being done (you'd get in huge trouble if we somehow didn't review a task), the problem was they were being done on the master branch after-the-fact, e.g. I could put or break whatever I want in the master and no one would know until someone got around to reviewing it, which could be up to the next day.
|
|
#
?
Oct 1, 2013 16:55
|
|
|
Plorkyeran posted:After-the-fact code reviews pretty much aren't code reviews in the sense that most people mean. Requiring that all code be reviewed before it's pushed to trunk results in a pretty fundamentally different workflow. Yeah, I've always enforced code review before it even leaves a dev branch. If someone wrote lovely code, why should that code escape into my other branches?
|
|
#
?
Oct 1, 2013 17:03
|
|
|
Mr. Crow posted:@git-flow, I don't think it will really work for us based on my original comments / the observations that were made to me.
|
|
#
?
Oct 1, 2013 19:27
|
|
|
Ithaqua posted:You shouldn't use the term Agile if you're not actually doing Agile development. I'm not going to get into a pissing match; we are and it's not relevant to the question(s) at hand Gazpacho posted:I think I understood pretty well. If you have problems with people checking in build breaks, then your reviews probably should happen before any non-trivial commit to the master branch, not after. You probably would do well to have some kind of buddy build service. (Send it a diff, it builds that diff against the master branch and posts the result somewhere.) Ithaqua posted:Yeah, I've always enforced code review before it even leaves a dev branch. If someone wrote lovely code, why should that code escape into my other branches? This is exactly the problem I didn't think it was that not-obvious  The intent from everyone is to do work on a branch and get it reviewed before it gets "released", originally that included doing the reviews on the branch before merging it in, then I guess because SVN was so slow and we have a pretty huge code base people got tired of having to pull down a branch constantly to review it and/or there were some technical issues; whatever I'm not going to speculate, it was before I got here and it's not important. The end result is somehow the reviews started getting done on the main branch, which as I originally stated, is unacceptable. Telling me "well if you're having problems with broken builds you should make sure code gets reviewed before it goes in the main branch" is silly. Derp, that's what my post is about, fixing that issue (and others); reiterating the problem and hand-waving a general solution when I've already long since established them doesn't give me confidence that you understood the (admittedly long and possibly rambling) post. Anyway I think I've established how I'm going to proceed, so unless someone has a relevant observation, thanks for the responses 
|
|
#
?
Oct 1, 2013 21:55
|
|
|
Mr. Crow posted:I'm not going to get into a pissing match; This isn't a great way to encourage people to help you, FYI. Though I guess based on your post, you've already got everything figured out!
|
|
#
?
Oct 1, 2013 23:01
|
|
|
Mr. Crow posted:The end result is somehow the reviews started getting done on the main branch, which as I originally stated, is unacceptable. Telling me "well if you're having problems with broken builds you should make sure code gets reviewed before it goes in the main branch" is silly. - Code review portal - Buddy build service - Dev accountability (broke-it/fix-it policies) - Bug-fix cycles. All of these are independent of what source control technology you're using. If you're going to replace your core dev infrastructure, you should have a clear reason for doing so.
|
|
#
?
Oct 1, 2013 23:56
|
|
|
if you want enterprise support, go for Stash especially if you have Jira already
|
|
#
?
Oct 3, 2013 18:23
|
|
|
Mr. Crow posted:I don't really see it as an issue at all. ok well it sounded from your problem description that you felt it was a problem so ok whatever.
|
|
#
?
Oct 3, 2013 19:42
|
|
|
If, like me, you use Bitbucket for Mercurial hosting, and if, like me, you would like it if they supported the "largefiles" Mercurial extension, please add your vote (and optionally a comment) here: https://bitbucket.org/site/master/issue/3843/largefiles-support-bb-3903 That is all.
|
|
#
?
Oct 9, 2013 08:10
|
|
|
Gitlab looks great, but it's pay? Or am I missing something?
|
|
#
?
Oct 9, 2013 16:15
|
|
|
Megaman posted:Gitlab looks great, but it's pay? Or am I missing something? No, there is a for-pay edition with professional support and a couple very minor extra features. If you want to install and manage it yourself it's free.
|
|
#
?
Oct 10, 2013 04:36
|
|
|
Arcsech posted:No, there is a for-pay edition with professional support and a couple very minor extra features. If you want to install and manage it yourself it's free. Ah ok, I'll try the free version, I don't need no stinking support.
|
|
#
?
Oct 10, 2013 19:47
|
|
|
mnd posted:If, like me, you use Bitbucket for Mercurial hosting, and if, like me, you would like it if they supported the "largefiles" Mercurial extension, please add your vote (and optionally a comment) here: Commented / voted I think.
|
|
#
?
Oct 11, 2013 15:16
|
|
|
Looks like we're going with this. We want to move to git, but the Director of Development doesn't want to have to go beg for money to move. Thanks for the suggestion.
|
|
#
?
Oct 16, 2013 18:44
|
|
|
While I still hate how so many companies use git in a purely non-distributed fashion, I did just send that link out to replace our gitolite install.
|
|
#
?
Oct 17, 2013 14:12
|
|
|
Do any of the various SVN GUI applications for UNIX/Linux stand out above the others or are they all pretty equal?
|
|
#
?
Oct 19, 2013 00:12
|
|
|
Looks like Github is down again. They are seriously not a company that can afford downtime.
jiggerypokery fucked around with this message at 13:41 on Oct 19, 2013 |
|
#
?
Oct 19, 2013 13:38
|
|
|
Hughlander posted:While I still hate how so many companies use git in a purely non-distributed fashion man you have no loving idea
|
|
#
?
Oct 20, 2013 01:39
|
|
|
Marsol0 posted:Looks like we're going with this. We want to move to git, but the Director of Development doesn't want to have to go beg for money to move. Thanks for the suggestion. gitlab enterprise is stupidly expensive, we got a quote of like 50k/year and we're a pretty small shop
|
|
#
?
Oct 20, 2013 01:40
|
|
|
|
| # ? May 12, 2024 15:14 |
|
|
The regular gitlab is still self-hosted, you don't need enterprise. Also gitlab enterprise is only $20/year/user. GitHub Enterprise is I think $5k/year/20 users which does seem kind of high but not that unreasonable.
|
|
#
?
Oct 20, 2013 04:28
|
|