subdirectory clone/pull/update?
Martin Geisler
mg at lazybytes.net
Sun Aug 29 20:04:50 UTC 2010
Ethan Tira-Thompson <ejt at cmu.edu> writes:
> Hi all,
>
> I’ve hit a major stumbling block for switching to mercurial. (Please
> also see my previous email) We have a large software package with a
> number of different tools and a large chunk of code which is compiled
> into a shared library. We also have a ‘project’ directory, which
> provides data files and some boilerplate for users to write an
> application using the library.
>
> So the common workflow is to copy our package to some common location
> like /usr/local, and then users (students actually) can copy just the
> project subdirectory to start a new application.
>
> As we develop the software, sometimes we make changes to the project
> boilerplate, or add data files for a class assignment, and it is very
> convenient to use the SCM to synchronize these, so the students can
> just do an pull/update in their project(s).
>
> Suggestions? Mercurial doesn’t seem to support subdirectory updates,
> or does it?
No, Mercurial is structured around repository-wide changesets (commits)
that capture the state of the entire project.
So perhaps you should make one Mercurial repository for the library and
then make other repositories for each project that uses that library.
> Obviously, we could have the ‘project’ as a completely separate
> repository, but this is also annoying: new, non-classroom users will
> have to checkout two repositories, and will likely wind up missing one
> or the other, and also our own developers typically just use the
> ‘project’ embedded in the library and if these are separate we will
> forget to update both and we’ll have issues with them falling out of
> sync.
Well, keeping the library separate from the project that uses it sounds
like a sensible practice... but if you want to embed the repository
containing the library within a repository for a project, then checkout
the subrepository feature:
http://mercurial.selenic.com/wiki/Subrepositories
This is the closes equivalent to svn:externals, which you may be
familiar with.
--
Martin Geisler
Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100829/858e927e/attachment.asc>
More information about the Mercurial
mailing list