Jump to content

Common Library Repo Setup


dpadlewski

Recommended Posts

We want to create a repo where we store all the libraries for our projects (frameworks like Nhibernate, Spring, Log4net, etc.)

In our projects we would set our selectors accordingly so that we pull the paticular libraries needed for the project (and version of library).

Is there some suggestions on how to organize the repo?

I was hoping to keep the libraries in one repo called CommonLibs and have branches for each framework, and possibly a few branches to merge various other branches togeather.

So rather than a main branch, I could have branches as so:

Spring (for spring framework, with labels for the various versions of spring)

NHibernate (for NHibernate, again with labels for the various versions)

etc.

Is it possible to have various unrelated top level branches?

If so, can I merge the Spring and NHibernate branch into another single branch (just to make selectors a little cleaner on referencing projects)?

Any advice is appriciated.

Thanks.

Link to comment
Share on other sites

Hi,

This one sounds like an advanced topic! Great!

Yes, it's possible to have 'top level' branches, but let me explain a little bit how it works.

When you create a repository you get a /main branch. /main is a top level branch with a 'special feature': it has a revision of the root directory. That's why you can 'mount it' on a workspace and get the root item there.

So, suppose you do something like:

cm mkbr br:/master

cm stb br:/master

You'll get an error because the selector can't locate a root item, and hence it can't load anything.

BUT, let's try a small trick:

Edit your selector and type something like

repository "test"

path "/"

branch "/master" checkout "/master"

path "/"

branch "/main" co "/master"

Now a cm ls will show:

07/05/2010 00:22 dir br:/main#0 .

Meaning you're able o load the root item. Cool.

Notice that the second 'selector rule' says: "hey, when you perform a checkout, put the new revision on 'master' instead of /main'.

Let's do that:

cm co .

cm ls

07/05/2010 00:26 dir br:/master#CO CO .

Now we've a revision of the root item on /master!

We can add some content there or simply do a forced checkin:

cm ci . --nchk

cm ls

07/05/2010 00:27 dir br:/master#0 .

So, now try the following (more standard) selector:

repository "test"

path "/"

branch "/master" checkout "/master"

And now it works! (cm stb br:/master works ok now too).

Now you've a fully featured top level branch able to work the way you want to, you can add content there and later use it as starting point for your 'mount' operations. You can also create child branches and so on.

It's all about understanding how branches work on Plastic. In fact at the very beginning we only had top level branches but we created 'child branches' as a way to simplify selectors, that later were totally replaced (for normal operations) by the GUI and 'stb' command which handle them behind the scenes.

Don't hesitate to ask if you've questions! This is a complex topic :-P

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...