Chunks?

Benoît Allard benoit at aeteurope.nl
Tue Dec 6 07:03:09 CST 2011


On 12/6/2011 11:02 AM, Steve Dyer wrote:
> The next steps were to clone this 5 times.  The reason is that currently
> we have a single "core" codebase, and this then feeds into 5 sub code
> bases.  The idea is that all of these 5, whilst different variations,
> need to share a common area so that we can pump new features etc back up
> to the core, and then down to the other variations from time to time.
> Our current code environment matches this layout, and each of these 5
> sub repos has variations to the core.  So the next steps were:
>
> 4. Clone repository
> 5. Overlay existing code into new repository
> 6. Commit
>
> And these steps were done 5 times to create my 5 clones.
>
> So, with all that in mind, have I needlessly bloated my repositories
> now?  I know that a clone will share the full history, so is it because
> of this that my new clones now take so long to "download"?
>

Often, the conversion from a VCS to another can be seen as a chance for 
you to re-organize your code into "units" or "modules". While in your 
previous setup, you probably had one huge repository, the usage, when 
using a DVCS (decentralized) is to use multiple smaller one. What this 
mean for your setup is that you can put your common code into a "common" 
module, and the specific code into others modules. This leads to at 
least those advantages:
- Repositories are smaller
- When looking at the history of the common module, you don't need to 
filter out the history of the rest, as it is in another module (another 
history).
- Not everyone needs to have all the source code locally.

My advice for you at this moment would be to sit down and think about 
all the related improvement you can bring while changing VCS.

Hope this helped ;)

Regards,
Benoit

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4936 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial/attachments/20111206/0994252f/attachment.bin>


More information about the Mercurial mailing list