I got SVN Server setup for Project A which is all good.
I now need to setup another repository in the same server for Project B.
Any guidelines please?
Creating a sub-folder as Arpit suggests is definitely not the solution you're looking for, since both projects would be part of a single SVN repository, hence, sharing revision numbers.
It is definitely possible to have several repositories in a single server, however there are many ways to do it depending on your setup.
First you might want to study these documents to get your concepts straight.
http://svnbook.red-bean.com/en/1.7/svn-book.pdf
http://tortoisesvn.net/support.html
In a Windows Setup, for example, VisualSVN, through its managing tool, VisualSVN Server Manager, allows you to easily create and manage repositories in a straightforward way.
It is important that you undrstand the difference between repository as a general concept, and repository as a technical term in SVN. The cited documentation will assit you in this.
If you are using Apache, you can support multiple repositories easily with SVNParentPath configuration. See
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html#svn.serverconfig.httpd.basic for details.
You have installed a server and setup a project in it, I believe in the following manner:
http://svn.exampel.com/repos/
|
|- ProjectA
|
|- branches
|- tags
|- trunk
To add another repository in the same server, just go to the root directory and create another folder structure like this:
http://svn.exampel.com/repos/
|
|- ProjectA
|
|- branches
|- tags
|- trunk
|
|- ProjectB
|
|- branches
|- tags
|- trunk
Simple!. There is no other configuration invoved and you can start using them as seperate repositories. This is called a Multi-Repisotory Layout.
NOTE: The revision number will be shared with both of these, i.e., the revision number is for a complete tree and there will be a unified revision number for both the projects
Related
I'm working on different projects based on node, and one thing I always have to do is create the configuration files in all the projects since you all share a lot of configuration, for example, in all projects I use commitlint, lint-stage, husky, eslint, nodemon, and typescript and other settings.
How could I share all these settings in all projects and if I update any of them, update them in all projects?
The first thing that occurs to me is to create a npm packet with all the configurations, and several scripts, that copies / updates these configuration files in the root directory of the project where user is, something like
> myscript update
> myscrpt init
Another option would be to use the configurations programmatically, that is, instead of using a .rc use a .js, but this would force me to manage the dependencies in each project and create a .rc file that uses the configuration of the js file which is in the configuration package.
Another option is to create a github repository as a template, but if I update this repository, the projects I have created using this template are not updated, right?
What do you think is the best way to do it?
Even though git submodules seem to be discouraged lately, I think it's the most reasonable choice (assuming all of your projects are git-based): https://git-scm.com/book/en/v2/Git-Tools-Submodules
In your case, you'd have a 'common' repository with configuration, eg. configuration and two projects: projectA and projectB. Both of them would have the submodules added:
git submodule add <your_git_repo_server>/configuration
Please notice, however, that submodule refers to a particular commit (not a branch or tag - commit). You always have to take big care of synchronizing your dependencies correctly.
I have a multifolder project that I want to push to a remote repository. It's a pretty standard issue structure with a root folder that contains a client and a server. For some reason when I want to stage this, server is the only file acknowledged and committed. When it's pushed to GitHub, the repository shows both client and server folders, but the server(which I built from scratch) is the only one that contains files and folders. The client folder(which is built from create-react-app) is an empty folder.
Root_
|
client(create-react-app client)_
| _.gitignore
| _package.json
|
server_
_.gitignore
_package.json
In other projects I've built everything from scratch and there's been no problem, so I figure it has something to do with the existence of two .gitignore files, two package.json files, or the create-react-app itself. I've searched for answers here and in git's documentation. I attempted to use submodules and nothing I've found so far seems to work. Any help would be appreciated.
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).
I am working on a Magento store (SVN repo connected to Git) utilizing the fabulous HTML5 Boilerplate based Magento-Boilerplate theme (GitHub repo) and extending it with my own child theme (private Git Repo). These all exist in a single www folder which happens to be the top level directory for all three projects. I would like to cleanly integrate all of these into their respective repositories, but the only solutions for multiple repositories in a single directory that I have found are submodules (which I love the idea of, but as far as I can tell require each project to be in a subfolder of the main Git repo) and symlinking the files into place (should work, but a bit messy and rather annoying to keep up).
Is there a clean way to get this done? Here is an example of my folder structure. I have denoted in which repo(s) each file/directory resides - M = Magento, B = Boilerplate, P = Private:
/www
|-- app [M]
|-- frontend [M]
|-- base [M]
|-- magento-boilerplate [B]
|-- default [B]
|-- myprivatetheme [P]
|-- skin [M]
|-- frontend [M]
|-- base [M]
|-- magento-boilerplate [B]
|-- default [B]
|-- myprivatetheme [P]
|-- .htaccess [M][B][P]
|-- favicon.ico [M][P]
As you can see, even without the whole .htaccess and favicon.ico being in multiple repositories mess (I would just gitignore or --assume-unchanged them in the Magento and Boilerplate repos and use my private one for them) the top level directory is www due to the way that Magento splits code and themes into separate folders with a common parent of www. Due to that you can even technically say that the app, skin, and various frontend folders exist in multiple repos as well, since they must exist in each repo all the way up to the top level directory for structure.
Is sym-linking these repos in from separate folders my only solution? It's not a huge problem, but I would be really interested to know if Git is flexible enough to deal with my case. It looks like modman may have been created specifically to aid in this symlinking issue.
I confirm there is no easy way to map a Git repo structure to a deployment structure (which is essentially what your folder structure shows: a deployment into a web folder)
"modman" seems to be a valid way to automate, but you need to remember that if you do any change in one of those submodules, you will need to commit them, push them to their respective upstream, and go to the parent git repo, commit again and push.
All that doesn't seem to be taken into account by modman.
The OP Colt McCormack reports studying modgit:
modgit is an alternative to the excellent modman tool.
Directly inspired from it, modgit allows you to deploy Git modules physically in your project (no symlinks).
Additionally, you can define include/exclude filters to deploy only files and folders of your choice.
The tool vcsh was made for organizing the files in $HOME in several repos (ssh, zsh, vim, emacs, …) without using symlinks. vcsh uses fake bare git repos for this. It also works together well with mr which was made to easily organize multiple repos (synced pull, push, …).
Although vcsh was intended for $HOME it can be used for any directory.
vcsh's readme file is a great start and should help you (decide) if it's the tool you're looking for. Richard Hartmann, the maintainer of vcsh, talked about it at FOSDEM 2012: info – slides – video
There is also multigit.
Multigit allows you to check out multiple git repositories over a common directory and provides simple tools that let you continue to use git as before, without multigit getting in your way.
It is useful for projects which are made of different components that are developed separately, but which need to deploy files in different parts of the directory structure of the project.
This cannot be done using git submodules or git subtrees, which only allow subprojects to deploy files in their own subdirectory. Multigit allows subprojects to deploy files in any directory of the project, similar to a union filesystem, where each repository is a layer.
Some examples where this combination of change management and module management could be useful:
manage customizations made to a web app in a separate repository.
putting your home directory under source control.
package and/or config manager for a Linux distro.
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.