I have a project I'm currently working on, which I am contemplating making open source, but I definitely want to keep it closed-source for the time being. Inside this project, I have a sort of subproject that I want to make public, so anyone can access/fork it.
So here's what I want:
A mercurial SCC with:
Repo 1: All files from /dir/project/ - Private repo, requires username/password to pull/push/fork/browse etc.
Repo 2: Some files from /dir/project/stuff - Public repo, but requires username/password to modify.
How can I do this? Is there a better way I can do this? I'm using my shared hosting Linux environment to do this, so is symbolic linking a better idea?
I'm open to all suggestions thanks, still a bit of a HG newbie.
You should use "subrepository" to define the two parts of your project:
your parent repo would be the private one, with a reference (in a .hgsub file) to your public repo ()
your public repo woud be stored in a public referential, with no knowledge of the private part.
(No symlink necessary here)
See also in the same kind of problem the SO question "Mercurial Subrepos - How do you create them and how do they work?".
Subrepositories is a feature that allows you to treat a collection of repositories as a group. This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group.
Related
There is an unstable gitlab server and I am not sure that it will be able to work in the future. Therefore, I want to make a backup copy of all the repositories (projects) that are there.
Cloning the source code will be enough, but it will be great if there is a way to save issues as well. Are there any ways to do this?
It depends on what kind of access you have, but if you don't have administrator access to do a full backup, then the best thing to do is to use a couple of API endpoints to get the information you need and go from there.
Use the Projects API to get a list of all projects accessible to you.
Note the pagination limits.
What you store depends on how you want to get the information.
Store at least the ID number of each.
Filter by membership if you only want the ones you're a member of.
Filter by min_access_level = maintainer (or higher) if you want to export whole projects.
Use the Project export API to trigger a project export for each project you're a member of, and you're a maintainer (or higher).
For all other projects where you have a lower role, or where it's public, you could still use git clone for the repositories by storing the ssh_url_to_repo or http_url_to_repo from the Projects API and running through each.
For all other parts of a project, you could store the JSON version to recreate them later if you want to go through the hassle. For example, for issues, use the Issues API.
I started exploring Gitlab for version control management and I got an issue at the first step itsself. When ever I create a project its creating a new repository. I have few webapplications which are independent to each other. In that case do I need to use different repository for every project.
What I am looking for is what is what and when to use what but not able to find what is repository and what is project in gitlab website as well as through other sources as well.
Also I came across a term submodule, when can it be used. Can I create one global project and have all the webapplications as different submodules.
Can any one please help me in understanding the difference between those 3 and when to use what based on their intended way of usage. Also please help me by pointing to a good learning site where I can get the information of doing basic version control operations in gitlab.
Thanks.
Gitlab manages projects: a project has many features in addition of the Git repo it includes:
issues: powerful, but lightweight issue tracking system.
merge requests: you can review and discuss code before it is merged in the branch of your code.
wiki: separate system for documentation, built right into GitLab
snippets: Snippets are little bits of code or text.
So fear each repo you create, you get additional features in its associated project.
And you can manage users associated to that project.
See GitLab documentation for more.
The Git repo and Git submodule are pure Git notions.
In your case, a submodule might not be needed, unless you want a convenient way to remember the exact versions of different webapp repo, recorded in one parent repo.
But if that is the case, then yes, you can create one global project and have all the webapplications as different submodules.
Each of those submodules would have their own GitLab project (and Git repo).
We have a bunch of small projects that have a single repository in Gitorious. Most of these repositories are really related. Had the foresight been put into the original creation, these would have all been created under the same project.
Now that there is all of this sprawl, is there any way to keep the repositories (or at least their history) intact, yet group them under a new project?
There is no such move option in gitorious.
The only way I know is to create a new repository inside the target project and then push the code to this repository. Afterwards, you can delete the repository. Note: moving the repository will update the associated URL. This will require coordinating the new URL with any local clones.
I have a project that I am developing built off CodeIgniter. The main part of the project is a private system I am creating, but I want to add it to source control, to gain all the associated goodies. Now I'm using Mercurial, so I did the whole hg init bit, so I've got the repository set up.
Now, one of the things I've done is to make a library for CodeIgniter, which I use in this project. Now I want to make this library open, so I need a separate repo for that.
For anyone unfamiliar with CodeIgniter library development, here's a reference:
application
/config <- configuration files
/libraries <- library logic in here
Now I will probably develop a few more libraries in the course of this project, so I can't just dump a repo in the application folder without clumping them all together.
What I did was this:
dev/ci/library <- library here
dev/project <- project here
Now in both of those folders, I have made a repository. What I want to do is make the project repository automatically reference the library repository, so I can have a private and a public repository, as I explained earlier.
The main way to do this, I have read, is to use subrepositories, but I can only find examples on nested ones (which are unclear anyway, I find). How do I make it reference another repository like svn:externals?
You are correct, subrepos in Mercurial (or submodules in Git) are based on a nested organization.
But in your specific case you need:
two separate repos,
not nested
A way to reconcile both organizations (yours and the nested "subrepo") would be to have three repos
a parent repo (private one, as in can be pushed to a private repo)
the project (private one, as in can be pushed to a private repo)
the library (public one, as in can be pushed to a public repo)
That would give the following:
/dev
.hg (private repo)
.hgsubs (declare the two nested repos 'project' and 'ci/library')
project
.hg (private repo for your project)
config
.hgignore (for ignoring anyhting from libraries)
libraries (private directory, not version)
(symlink to /dev/ci/library)
ci
library
.hg (public repo
That way, you keep:
your two repo separate as you want
a link between the two in order to be able to get back those two repo at the exact reference you left them (i.e. you last pushed each of those repos).
Implemented in Mercurial 1.3, here's the instructions.
How do you set up a git repository where some users can see certain parts of the source code and other users can see all of it? I've seen lots of guides for only giving certain users commit access, but these assume everyone should have read access. I've also heard of gitosis, but I'm not sure it supports this and it hasn't had any commits in over a year so I think it's dead.
In short: you can't. Git is snapshot based (at conceptual level at least) version control system, not changeset based one. It treats project (repository) as a whole. The history is a history of a project, not a union of single-file histories (it is more than joining of per-file histories).
Using hooks like update-paranoid hook in contrib, or VREFs mechanism of gitolite, you can allow or forbid access to repository, you can allow or forbid access to individual branches. You can even forbid any commits that change things in specified subdirectory. But the project is always treated as a whole.
Well, there is one thing you can do: make a directory you want to restrict access to into submodule, and restrict access to this submodule repository.
The native git protocol doesn't support this; git assumes in many places that everybody has a complete copy of all of the history.
That said, one option may be to use git-subtree to split off part of the repository into its own subset repository, and periodically merge back.
Git doesn't support access control on the repository. You can however, implement access control on the repository yourself, by using hooks, more specifically the update hook.
Jörg has already pointed out that you can use hooks to do this. Exactly which hook(s) you need depends on your setup. If you want the permissions on a repo that gets pushed to, you'll need the update hook like he said. However, if it's on a repo that you're actually working in (committing and merging), you'll also need the pre-commit and post-merge hooks. The githooks manpage (Jörg linked to this too) notes that there's in fact a script in the contrib section demonstrating a way to do this. You can get this by grabbing a git tarball, or pull it out of git's gitweb repo: setgitperms.perl. Even if you're only using the update hook, that might be a useful model.
In general, Git is not intended for this. By now it seems to have out-of-the-box access control only up to the repository level.
But if you need just to hide some part of secret information in your Git repository (which is often the case) you can use git-crypt (https://github.com/AGWA/git-crypt) with encryption keys shared based on users GPG keys (https://gnupg.org/).
Alternatively you can use git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules) if you can break your codebase to logical parts. Then all users receive access only to certain repositories which you then integrate into 'large' codebase through sub-modules where you add other code and allow it for only 'privileged' users.