we have around 50 mercurial repositories, running in a rhodecode instance and i need to maintain their hooks, e.g. to trigger hudson builds.
I'm not very adept with sed/awk etc, so maintaining the hooks is a constant struggle for me. Most hooks would be almost identical over all repos (just the local repos URL might be different, or i might want temporarily so "switch off" certain hooks for certain repos)
Is there a tool to ease this task? Or maybe a best-practice-setup where those hooks are just "stubs" that invoke a central script where the actual work is happening?
Best Regards
PS: my apologies if this question is already answered, i find it hard to believe that it's not, but i didn't find any answer..
Easiest ti achieve that is using rcextensions of RhodeCode. You can connect to global post-push hook to trigger hudson builds. This is a global hook that is called for all repositories. This combined with extra_fields functionality of RhodeCode allows you to do customization of certain parameters, or even control
Related
The company I work for uses TFS for its version control and has quite a strong opinion on data security.
With that in mind I'm unable to use source control services such as git due the capability being there to push your work to an external source.
My question is are there any git-like ways to manage your code which are PURELY LOCAL and do not offer the ability to push your changes to the internet? TFS does not seem to offer much in the way of local commits.
I've been told there's the shelving function however as a junior dev I would rather make any accessible code be in good standard before others can see it.
Thanks
I'm unable to use source control services such as git due the capability being there to push your work to an external source
That sounds like a rather odd reason. Even if you use a source control tool that does not support publishing the stuff, there is nothing that prevents you from simply uploading the contents manually somewhere. Sure, it requires manual work, but even that you could automate without introducing a version control system that does it.
The way you explain this also sounds as if you do have some kind of control of the tool you may end up using for this, so the company needs to trust you anyway to not publish the stuff.
And at that point, there is no reason not to use Git here: After all, it works completely offline, and you do not have to set up a remote which you could push to.
Taking things even further, if your company works with TFS, then you could utilize git-tfs which is a bridge between Git and TFS. With it, you can actually connect to your TFS, use Git locally, and then publish your changes (after you polished them) to the TFS. So it would all be a single integrated workflow, without you having to juggle between two different incompatible systems: You just commit using Git, and once you have a set of commits ready for checking them into the TFS, you can e.g. do git tfs checkin and make a single check-in for it.
I've been told there's the shelving function
The TFS shelvesets are also not offline; they are public in the same way the normal checkins are, it’s just that they live on the side without affecting the normal TFS repository. And they are quite cumbersome to work with too (since they don’t give you a history).
I've searched for what the title mentions and I've read this and this and a few others that I can't find at the moment. But I've never used any sort of version control before, so I don't really understand a lot of what those threads are saying.
My problem is this - There are two/three of us on a LAN connection developing code, and every week or two we have to go around to figure out who has changed what and then synchronize all the code over the machines. This is clearly ridiculous, so I was wondering if a system like git or cvs (I don't know anything about either) would help.
I don't think using one of the machines as a 'server' is a good idea, because they may not always be switched on.
What would be a good version control system to use? (Preferably without a really steep learning curve, but anything is good.)
You can select and use any DVCS (D means "Distributed") in pure distributed mode (only p2p data-exchange).
For mixed environment (Windows-hosts in game) I'll suggest to forget about mentioned earlier here Git and use Mercurial (as Mercurial per se or as TortoiseHG), because
Nercurial just better
Mercurial (contrary to Git) have really easy and lightweight learning curve (you can start at Mercurial Kick Start Exercises, maybe on "Basic Mercurial" and "Remote Repositories" only)
I agree you should use a distributed version control system. Git is a good choice. With a distributed version control system, you don't need a server at all. That doesn't mean you can't have one though. Using an online one like github.com is advisable in case you lose access to your computer or a virus goes around the network or ...
You could use Git and Bananajour.
Git is a distributed version control system, you dont need a server to save your commits. http://git-scm.com/
Bananajour is a web front end for collaborating and publicizing branches on a network. https://github.com/toolmantim/bananajour#readme
You should take a look at any of the following:
Git
Mercurial
Plastic SCM (www.plasticscm.com) -> this is the one produced by the company I work for.
Any of them will let you implement new working patterns such us "feature branches" or "branch per task"
I've written a couple of posts about the working methods here:
http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html
And this one, about the git flow and related patterns http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
Hope it helps.
One possibility would be to use an "online" version control offered by a website like http://www.java.net/. There you can create a project, and after that create a repository that you and your friends could use. This will allow you to always access the respository since it's hosted by java.net.
Currently we are using SVN.
I would like to start using GitHub, but one absolute requirement is that we will need to have precommit (premerge) validation of the code like we currently have. Does GitHub support precommithooks (premergehooks)?
We're a team of 5 developers. We made an agreement that all code (JavaScript) should pass JSLint-like validation. Voluntary validation has proven not to work because it's easily forgotten. How can we be sure that code that becomes available to the others is guaranteed to validate against JSLint (or similar)?
The concept I was looking for was the prereceive hook
I don't believe github supports pre-commit hooks. However, the git core does. You could set up the pre-commit hooks locally, or apply them as a test before merging branches into your main github.
I think you're missing something fundamental about git. It's not a centralized model (well ok, it can be, but if you're going to use it this way then github is probably the wrong approach). If you're using github, the right way to do this is:
Host your main repo
Have your developers each create their own fork
Let them happily hack away, committing and pushing to their heart's content
When they think a feature is ready, they send a pull request to you (the maintainer) which you yourself verify on the side to ensure stability. Then you merge / rebase their changes into the main repo.
Naturally there are many ways to skin a cat. But when you're talking about "real git" (the kind employed by the open source community), the centralized "check-it-in-and-it-damned-well-better-work" model is kind of difficult, especially when it comes to larger projects.
I think this article describes a very good workflow that could be a basis for automation:
http://scottchacon.com/2011/08/31/github-flow.html
The main idea is that you use pull requests as mentioned above, but you can also have a service that can use the github api to fetch or pull the branch making the request, merge, test, validate then push to the target branch.
No, GitHub doesn't support pre-commit hooks. How would that even work? Committing happens on your computer, do you really want to allow GitHub to run arbitrary code on your machine?
The company I work for exclusively uses Clearcase. I feel it is not worth the effort to learn and use it as my project would not involve too many people(max of upto 3 people), neither would it involve fancy development flow. How do I convince my manager on using a separate source control for this when they bring up the point of "IT supported and uniform source control through out the company" against my suggestion? Or is that particular point valid and I should go with Clearcase?
Thanks...
PS: I was thinking of using Subversion.
If it's the company standard, then there should be people in the company that know it that can help you get started with it. They should be able to set up your particular IDE to work with it, and make everything as seamless as possible for you. You shouldn't have to learn anything crazy in order to use it - there should be clear instructions.
If there's not, then you're not getting the benefit of "IT supported and uniform source control through out the company" and it makes no difference what you use.
After working through this process, if an argument can be made that there's a better source control that would work better through the firm, you should make it. If it's a company standard, it shouldn't be a pain in the neck to use.
First of all, my condolences.
Is Clearcase that difficult to learn? If yes, I'd consider that a strike against it. If not, you might be better off just going with the flow and learning it.
The 3 people on your team aren't likely to be the ones that maintain the code over its software life, so that argument goes against you as well.
How big is the organization? It's easier for 3 people to learn Clearcase than for X to learn Subversion.
It would depend a lot on your boss and his/her willingness to consider alternatives.
Subversion would certainly be easy to set up and use. I'd hate to be using Clearcase myself.
But there are a lot of factors against you. Good luck.
If I were you then I'd want to use SVN because I just love it but just like anything with developement most of the time you have to go with the flow. Same as if you were extending a framework and you decided to do it your own way completely different to the rest of the framwork it would be frowned upon even if your way was much better. Also what would happen if you and your team got hit by a bus? OK SVN is easy to learn but there is still a learning curve that could slow down other people continuing your work.
You could also view this as a chance to learn a new source control system and make yourself more marketable. You could still prefer subversion, you can't be forced to change your opinion. As #Erick says if this is the company standard they should be able to support you and I'd hope you'd be able to get this factored into your timescales.
There's always the tried & true (albeit risky) approach of having your team use Subversion (how appropriate!) within itself and making the occasional show check-in to Clearcase.
Your argument against Clearcase
are
it is not worth the effort to learn
my project would not involve too many
people neither would it involve
fancy development flow.
Is it difficult to learn? If your company already using it, you will have many people to ask help from. Since your company already have clearcase, you are 80% done with clercase admin works. It will be fairly simple to create vobs, project etc.
In fact your project is small makes it more important to use standard within company. We had some fancy projects done using our standard SCM and some projects without the standard SCM. For the one which used standard SCM, when the projects is scrapped, the code is still safe with in organization. Other products, we lost people and code.
Are you using ClearCase with UCM? It is simpler than base clearcase.
As I mentioned in "Are There Any Reasons To Still Use SVN?", you can't just decide to put a new server on the side, especially for sensitive data like code sources. At some point, they need to be versioned in a central referential.
Any server for that kind of persistent and important data should be:
funded (you can't just manage a VCS on your workstation, you need an actual server)
supported (your jobs is to develop, not to manage /troubleshoot your team in term of SVN operations)
integrated (no problem on that front for SVN)
administrated (again, your job isn't to manage/monitor the SVN server)
documented (where is your SVN server?, what are the backup procedures?, is there any backup/DRP server?, ...)
For all those reasons, your manager might consider leveraging the existing infrastructure/support around the main VCS (ClearCase, condolences ;) ).
But that won't prevent you to manage a DVCS within a ClearCase snapshot view though.
I don't know Clearcase, so I can't say whether it's good or bad or how it compares to Subversion.
But the whole point of source control is that there's supposed to be a single repository where everyone knows they can go to check out their code. If one team uses Clearcase and your team uses Subversion and another uses Git and another uses CVS, etc etc, then anyone wanting to check out source code not only has to look in ten places, but they have to learn to use ten different source code control systems.
Unless you can make a case that Subversion is clearly better than Clearcase in some relevant and important way, I'd say just bite the bullet and learn Clearcase. If it was me, I'd see it as an opportunity to learn something new. After I did, maybe I'd conclude that Clearcase sucks big time and I should try to convince the powers that be to switch to something else. Or maybe I'd conclude that Clearcase was the greatest advance since the invention of USB. Either way, you now know a little more. If nothing else, it's one more bullet to put on your resume the next time you go looking for another job.
Are you working full-time for this company or is this a one-off project as a contractor?
If it's your full-time role as an employee then it's time to buy that "Clearcase for Beginners" book.
If you're looking to deliver a project quickly, then perhaps just keep your head down and use Subversion as an expedient. Ask someone to check the finished article into Clearcase as you run out of the door.
:)
Use a DVCS like Mercurial or Git and make a branch of it to keep synced up with ClearCase. Your team can do the day to day work using a better tool but your organization still has your work products accessible the usual way (which is important). Sync up with ClearCase on a regular basis, and consider adding the output of your systems DVCS log (eg hg log) to a file in the ClearCase branch, so people can see the more granular steps if needed.
DVCS systems are also usually pretty easy to set up, and often can be easily hosted on a network share or something like that. Since all developers will have a copy of the full tree it provides a certain amount of built in backup and redundancy.
This workflow is not uncommon -- gitsvn and hgsvn are both scripts people have set up to let them use those tools by themselves but sync up with folks on another repository.
I recently joined a project team that is using TFS (I have happily avoided TFS until now). I am trying to determine if there is a way to require a story/defect reference to be associated with every commit comment?
With Tortoise/SVN it was easy to add a requirement for a reference number to be required with each commit. Personally, I like to track every commit back to a user story or defect, so I am hoping there is a way make this mandatory in TFS as well? I searched SO and Google, and haven't found the magic "key words", so if someone can point me in the right direction, it would be greatly appreciated.
Note: Stories and Issues are stored in other tools and not tied to TFS in any way.
Can it be done? Yes. Is it easy? Fairly easy. However, two caveats. Caveat number one: you're going to have to write code. Codeplex has some good examples here. Additional searches on codeplex and on the almighty Google will locate you more examples.
The big caveat here is that check-in policies are client-side. Once you develop the policy, it will need to be deployed to all developer workstations. If the policy isn't installed? It is ignored. While I'm a big fanboy of TFS, this is one oversight that I can't believe is still in place after three major version releases.
You could create a server-side check-in monitor that examines the check-in and determines if the story has been associated. However, it will not prevent the check-in, but you can use it to alert someone to resolve it after the fact.
Switch to a DVCS system like Git (see this article on pre-commit hooks) or Mercurial (see this other article on pre-commit hooks) which DO have server-side hooks that can be overridden to do validation checks. :-)
Yeah, I know, not really the answer you were looking for but it is an alternative solution to the problem that some other SO users might find useful.
With the DVCS type of system, you can have a separation between hooks that run on the local computer and hooks that run on the server when your commit is pushed back to the shared repository. That kind of concept does not have a corollary in TFS. It can make some things easier for your developers. For example, every changeset that was committed to our shared repository had to have a ticket number attached in the commit message. Local pre-commit hooks guarded against changesets getting created (in Mercurial) that did not have proper commit messages.
With TFS's support for GIT in an upcoming release maybe things will be easier in this regard.