Need hints for Repository structure

[Alan Boudreault]

Hi,

Recently, I moved the company repository from CVS to Mercurial. Doing the
move... I tried to keep the same structure as it was before. I mainly only
separated the repository in 2 master repos: company-admin and company-proj.
The repository "company-proj" is relatively big and contains a lot of
different projects from different clients. Here's the structure:

company-proj/
company-proj/client1/
company-proj/client1/file1
company-proj/client1/proj1/
company-proj/client1/proj1/files_of_project
company-proj/client2/...
company-proj/client3/...
company-proj/client3/proj1/
company-proj/client3/proj2/
company-proj/client3/proj3/

The first thing I was sure at the beginning of the setup was:

- Cloning everything everytime everywhere is not a solution. The repository is
too big.
- The repository is huge.... it would be nice to be able to clone only one
client directory.
- A few projects are huge.... it would be nice to be able to clone only one
proj directory

So, I guessed the solution was to use "subrepos". Basicly all "major
directories are a subrepo. (client1, client2, */proj1 etc.) Unfortunately, I
realized that it was not as efficient as I thought. The issues 1886 and 1887
are a "problem" in these kind of structure. (
http://mercurial.selenic.com/bts/issue1886 and
http://mercurial.selenic.com/bts/issue1887 ) Also, I this structure is not
very good because the subrepos is not supported perfectly in other softwares:
hgweb and trac per example.

I tried to keep my structure simple and intuitive for all my colleagues, who
hadn't experience with mercurial before.

Does anyone could suggest me a better way to handle this kind of company
repository. What structure do you use?

Thanks!
Alan

--
Alan Boudreault
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Masklinn]

On 2 Nov 2009, at 17:50 , Alan Boudreault wrote:
>
> Does anyone could suggest me a better way to handle this kind of  
> company
> repository. What structure do you use?
Not having a "company repository". Because in CVS or SVN you can  
checkout sub-repositories, and because setting up repositories tends  
to be painful/annoying, it's usually setup as a single huge repository  
for pretty much everything.

In most DVCS, it's the other way around: you can't really clone sub-
repos and setting up repository is pretty easy (if not trivial), so  
people tend to setup repositories per project (or per feature using  
things like forests/subrepos at the project level).

Here, that's probably what I'd suggest as well: create a repository  
for each *project*, with some per-client grouping at the interface/
social level if needed but none at the "physical" level.
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Alan Boudreault]

Sorry Masklinn, I'm not sure to understand the following point:
"at the interface/ social level but none at the physical level"

Thanks,
Alan

On November 2, 2009 12:30:39 pm Masklinn wrote:

> On 2 Nov 2009, at 17:50 , Alan Boudreault wrote:
> > Does anyone could suggest me a better way to handle this kind of
> > company
> > repository. What structure do you use?
>
> Not having a "company repository". Because in CVS or SVN you can
> checkout sub-repositories, and because setting up repositories tends
> to be painful/annoying, it's usually setup as a single huge repository
> for pretty much everything.
>
> In most DVCS, it's the other way around: you can't really clone sub-
> repos and setting up repository is pretty easy (if not trivial), so
> people tend to setup repositories per project (or per feature using
> things like forests/subrepos at the project level).
>
> Here, that's probably what I'd suggest as well: create a repository
> for each *project*, with some per-client grouping at the interface/
> social level if needed but none at the "physical" level.
>

--
Alan Boudreault
Mapgears
http://www.mapgears.com
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Masklinn]

On 2 Nov 2009, at 18:38 , Alan Boudreault wrote:
> Sorry Masklinn, I'm not sure to understand the following point:
> "at the interface/ social level but none at the physical level"

You could present your repositories in client-specific pages/groups  
(instead of a flat list of all the repositories in the same hgwebdir  
view), but that's purely presentational, it doesn't have any impact  
(or source) in the structures of the repositories themselves.

Due to their flexibility, DVCS — I think — tend to encourage moving  
social concepts into the social sphere (rather than the technical  
one): DVCS don't have a (technical) notion of "central repository" the  
way CVCS do for instance, but most projects do have some kind of  
foremost/primary repository/source. It's a purely social construct  
(and it could change if need be). Well the view I suggest above is  
just that, not really technical but depending on the way your teams  
work (e.g. teams are client-based or something) it might make sense to  
build keep the concept of client at the social/interface level even  
though as far as the repositories go (the technical level) it doesn't  
really exist anymore.
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Alan Boudreault]

A problem that I see is that using something like that make the reliability a
little bit more complicated..... ie: for hgweb/hgwebdir and the trac browser
etc.

Thanks,
Alan

On November 2, 2009 01:03:23 pm Masklinn wrote:

> On 2 Nov 2009, at 18:38 , Alan Boudreault wrote:
> > Sorry Masklinn, I'm not sure to understand the following point:
> > "at the interface/ social level but none at the physical level"
>
> You could present your repositories in client-specific pages/groups
> (instead of a flat list of all the repositories in the same hgwebdir
> view), but that's purely presentational, it doesn't have any impact
> (or source) in the structures of the repositories themselves.
>
> Due to their flexibility, DVCS — I think — tend to encourage moving
> social concepts into the social sphere (rather than the technical
> one): DVCS don't have a (technical) notion of "central repository" the
> way CVCS do for instance, but most projects do have some kind of
> foremost/primary repository/source. It's a purely social construct
> (and it could change if need be). Well the view I suggest above is
> just that, not really technical but depending on the way your teams
> work (e.g. teams are client-based or something) it might make sense to
> build keep the concept of client at the social/interface level even
> though as far as the repositories go (the technical level) it doesn't
> really exist anymore.
>

--
Alan Boudreault
Mapgears
http://www.mapgears.com

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial