Is DVCS (Mercurial) not for me?

Question

I work for a company where we create many small client applications. We are several developers, but in most cases there is only one developer in the project.

Customer1 ProjectX App Tests ProjectY App Tests Customer2 Project2 Products Product1 Common 

Today, everything is stored in one repository.

The process is simple.

• The developer takes on a new project for the client
• Create a new folder for the project
• Code in a new project
• Do some maintenance in another project
• Check for Service Project Updates
• More work in the new project.
• Check out a new project
• Provide to customer

No tags or branches. Earlier versions are checked based on date.

This process has worked well for many years, but there are several pain points with the current tool (CVS).

• Slow. Checkout takes minutes, even if nothing has changed. History is stored on the server, so diffs takes too much time.
• Adding new projects. If you worked with CVS, you know what it looks like: add a folder, add files to a folder, add the following folder ...
• Unable to undo obvious errors (checking binary files, etc.)
• There is no support for renaming, which makes the necessary refactoring even more painful.

I have been using Mercurial privately for some time and would like to distribute it to all developers.

Maybe everything turned out wrong for me, but there are a few things that I don’t understand how to implement in our organization.

CVS entries are the current folder, but in Mercury they are repositories. In our case, this means that performing maintenance work in one folder will also lead to incomplete materials in another folder. (I suppose we could do hg ci ./** in the modified folders, but this is not allowed when merging, at least this is what the documentation says. If you are committing the result of a merge, do not provide any filenames or -I/-X filters. )

A common practice in Mercurial is to have one repository for each project.

One repository for each project is suitable for us, but it creates some other problems, for example:

How to manage multiple repositories on a central server?
If a developer creates a new project, he ultimately needs to push his changes. Just do

hg push http://localhost:8000/Customer1/NewProject

hg-webserver crashes with an ugly dump on the stack and the client freezes.

I understand that a developer needs access to the server shell in order to add a new repository to the configuration file and restart hgweb

An alternative is to use SSH or share (are there any advantages to using SSH instead of a shared file?)

 cd Customer\NewProject hg init hg clone --noupdate --pull . //mercurialshare\Customer\Project echo "[paths]" >.hg\hgrc echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc hg push 

It works, but a little difficult for some developers

All developers must have all projects.
(In fact, not all but many projects are connected, so they should be present, and the easiest way to have everything)

Since many existing projects and new ones are added weekly, we need a way to pull out all projects in one go, as well as clone new ones.

I thought subrepos could solve the "global" attraction, but the next line in the documentation is showstopper

"When we commit, Mercurial will try to create a consistent snapshot of the state of the entire project and its subheadings. He does this by first trying to commit to all modified subrepos, and then recording the state of all subrepos."

Revert to the only global commit repository issue.

(I tried several options for hg ci .hgsub .hgsubstate <subrepo> , but .hgsubstate seems to be updated only when fully committed. Other users will not see the project changes without an explicit hg pull --update in the project folder)

My real thinking is to have a batch file in the root directory that pulls all projects

Any other ideas on how to use mercury in our organization?

Edit

Thanks for the answer. I am currently evaluating how one repository for each project will work for us. I put the batch file at the top level

 FOR /F %%x IN (repolist.txt) DO ( If EXIST .\%%x\.hg ( ECHO Pull %%x hg pull --update --repository .\%%x ) ELSE ( ECHO Clone %%x mkdir .\%%x hg clone --pull %1\%%x .\%%x ) ) 

Answer 1

Your right to say that Mercurial is for one project per repo. It is also much better when you work this way, because the history of different projects is stored separately.

Trying to have multiple projects in a DVCS repo is just painful.

Personally, I prefer to serve projects via SSH rather than HTTP. One reason is the ability ...

 # hg init blah # hg clone blah ssh://server/blah 

If you work through HTTP, this does not work (as you know). I am surprised that this leads to a severe accident: - /

The subreposition method for getting all the projects is not quite the way you describe it. This does not mean that you have returned to global commits (projects can be developed individually), but the superproject stores the version of subprojects on which it depends. This is exactly what you want if you have (for example) a library as a subproject, but the release depends on the specific version. Effectively a subrepo link is a bookmark to another repo in a specific version .

Not quite what you need.

Perhaps the common material should be sub-repo projects that need it. Then each project can be frozen on a different version of the same code, and you have no problem. It needs a little thought.

Otherwise, the idea of ​​a script is probably the simplest.