Is there any distributed version control system capable to grant Read/Write access to users with sub-folder granularity level?
i.e. if I want to give access to /foo tree for UserA, and only to /foo/bar for UserB?
UPD as far as I understand, this is impossible for Git (it treats repository as a whole only). What about Bazaar and Mercurial?
UPD still looking for a better answer.
EDIT: Just checked the comments, OP is looking for both read/write access, hence retracting this answer.
Nope, its not impossible for Git. The Gitolite project is very mature and has provided fine-grained access permissions (repo/branch/directory/file level permissions) for many years.
A specific example on restricting changes to a single file is found here: http://gitolite.com/gitolite/vref.html#NAME
A few simple examples are here, and more detailed documentation on defining rules is also available here.
Edit: Added another link
A write protection can be added to Mercurial, Subversion or git by using SCM-Manager and the Path Writeprotect Plugin. You can define a path and users or groups with write access to it.
As #maxim1000 noted in a comment, the best way to accomplish this may be to run a Subversion server, which can do fine-grained access control for both reads and writes, on a per-path and per-branch basis. If users want the power of a DVCS client, they can then use git svn or hg svn to import the portions of the repository to which they have access into DVCS and interact accordingly. It should even be possible for someone with higher access to merge changes to a subtree from someone with lower access without losing the excellent merge tooling that the DVCS implementations provide.
Related
for a small startup , I employed some remote developers. However, I only want to reveal the necessary codes to a certain developer, not the entire source code.
is this kind of feature offered by GitHub? If not, please provide a workaround.
Many thanks
With git repositories in GitHub there is no way to prevent a developer from cloning the whole repository and GitHub can't filter the contents of the repository to leave out part of the data. Permissions in GitHub can only prevent access to a repository, make the whole repo read-only or grant write access to the repository.
If you really want to limit access, you'll need to split your solution into multiple pieces, each in their own git repository. You can then set permissions for each repository in GitHub.
As a developer myself I caution you against this. A developer with only part if the sources would have a hard time verifying their changes work in way you intend to and it might make it much harder for them to debug any issues that happen in development.
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.
Once again, I'm a bit stumped about the best stack-exchange site on which to post this question. But I think developers are best suited to answer questions about source control, so here it is.
I am considering a crowd-sourced, user-rated game development project and am wondering what, if any, source control and merging systems might best be capable of hosting the kinds of source control I'm interested in. By user-rated, I mean that there will be some kind of rating/voting system like that found here on StackOverflow. For some details on the project idea, you can read my posting about it at http://gamedev.enigmadream.com/index.php?topic=1589.0. What I think I need is:
Ability to branch by user and maximize merging capabilities. I know source control systems are mainly focused on branching by version, and we could maybe think of each user maintaining their own version. But I guess we need some really robust merging capabilities to maximize the abilities of one user to merge changes from another user into their own branch, for example. So I think I would like the ability for "cross-branch" merging without having to merge into the common root branch first. (I'm most familiar with Team Foundation Server (TFS), which doesn't easily support this.)
Massive branching and merging. If there are hundreds or thousands of people wanting to incorporate their own changes into the project, there could be a lot of branches, and the system would need to be able to handle that without a meltdown. A single user might want to create multiple branches deriving from multiple other users' branches under their own name too, ideally, with the ability to merge among them to some extent.
Permission control by branch. I see SourceForge supports Subversion and Mercurial, but does not currently support permission controls by path/branch on these (as far as I can tell), although that does appear to be a feature under consideration. Users should be limited from pushing their code into other branches. I suspect the normal operations for a user would be pulling edits from other branches into their own branch, and checking in additional changes in their own branch.
A voting system. I know I shouldn't expect a source control system to support voting natively, but anything that could contribute to making this possible would be helpful. For example, maybe a voting system would involve or rely on the ability to label the best edits from various branches and pull them into a single file based on a label or a set of labels. And anything that would assist in merging the results of a selected set of labels from various branches (perhaps applying a new label to the set) could help too.
Very few files and possibly no directories. I would be willing to give up the ability to manage a large number of files or directories in exchange to gain any of the above because the format for the game file I'm considering is generally contained in a single text (XML or HTML5 -- haven't decided yet) file. But this does mean that the system should be pretty good at merging edits to relatively large text files efficiently. I know Team Foundation Server does a pretty good job of maintaining just changes to a file. I hope other source control systems do at least as well.
Or is source control not the proper paradigm to be talking about here? Is there some other technology ideal for merging code like this, one that doesn't involve source control and/or branching the way I'm thinking about it?
Any VCS, because "...source control systems are mainly focused on branching by version..." is just wrong, VCS support diverged changes of code over time, nothing more and nothing less
Any DVCS, because they have reasonable good branch-merge capabilities from the ground
Mercurial, which have branch-level ACLs, SVN have path-based ACLs. And because Subversion have physical tree repository (at some degree), ACLs can be applied to any part of subtree, i.e to branches also
Any CodeReview tool, integrated with VCS and modified for specific-reqs
Fossil SCM is single-file portable EXE, repo - one file; any DVCS also add only one dir of repo to existing tree and handle big files without headache
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.
I'm wondering if there is any best practice for maintaining your source code under version control among different companies. In Open Source there is a maintainer, who receives patches, decides on them and applies them. But what about closed sourced projects where different companies get different workloads and just commit them to the trunk and branches? Is this maintainer concept applicable to a project on which multiple companies work on?
You can choose from a wide range of version control systems. (Not only subversion)
With the "versioning" concept you are safe that no one damages the project permanently.
So there is no need for a manual approval process, especially when there are contracts for example between the participating companies.
I'd also set up a commit mailinglist so you have some kind of peer review of changes. So no changes can be done without anyone noticing them.
If applicable set up some kind of continous integration environment to keep the quality up.
I don't understand the question about the branches. The decision whether to use them or not is IMHO not depending on the fact that the commiters are employed in the same company or not.
Its really up to you to decide which workflow works best for the companies involved. Subversion has the ability to add permissions to your trunk and branches allowing you to lock down certain parts of your repository to people who are "trusted" with merge access to trunk. You'll need good communication amongst the companies. Using the open source Trac provides a wiki, integrated RSS feeds of the commits to the project and code browser.
Usually, each site works on its dedicated branch and can import the other remote site branch, to decide what to integrate in its own work.
But if a site need to work directly on the other site branch, one possible practice is the concept of branch membership which allows only one site at a time to work on a given branch.
(not sure it is possible with SVN though)
That allows for two remote site (with a large time shift) to work on the same task in a tightly integrated manner.
My recommendation : subversion, with that configured you give away a url and then checkout, update, get things done and when you guess that the project is ready, snapshot and deliver.