monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Sharing subprojects between projects


From: Anthony Williams
Subject: [Monotone-devel] Re: Sharing subprojects between projects
Date: Thu, 14 Jun 2007 13:49:48 +0100
User-agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.19 (windows-nt)

Richard Levitte <address@hidden> writes:

> In message <address@hidden> on Thu, 14 Jun 2007 13:21:36
> +0200, Ludovic Brenta <address@hidden> said:
>
> ludovic> I used Monotone's merge_into_dir for that purpose once.  I
> ludovic> suggest you have a look at it.
>
> It's true that it's (well, it and the subsequent propagates) the most
> supported way to do this.  The flip side of the coin is that it
> requires that maintainers of the subprojects remember to do the
> subsequent propagates a little now and then, which doesn't scale well
> for popular subprojects (libraries, for example?).

Also, in my case it doesn't work so well --- I would like to make changes to
the subproject as appropriate to the master project it's being used in,
optionally propagate these changes back to the subproject branch, and still be
able to pull in changes made to the subproject elsewhere. Quoting my original
posting:

Anthony Williams <address@hidden> writes:
>>     project1/
>>         project1.cpp
>>         shared_project/
>>             file1.cpp
>>             file2.cpp
>>     project2/
>>         project2.cpp
>>         shared_project/
>>             file1.cpp
>>             file2.cpp
>>
>> I tried using merge_into_dir to add the shared_project files as a subdir of
>> project1, which sort-of works, but now I have to remember to pluck the
>> changes back to the shared_project branch. Also, if I add a file in
>> project1/shared_project and then pluck that change back to shared_project,
>> then a subsequent propagate will break, complaining that the two adds
>> conflict.

Is there a way to resolve this automatically? The file in question has exactly
the same contents on both branches, but propagate fails because it was added
independently.

> As an alternative, I could easily imagine having a file _MTN/subdirs
> or something like that in the main workspace that describe
> subdirectories that need to be treated as separate workspaces in a way
> that's transparent to the user.  Unfortunately, that would require
> that each user is informed of the relationship between projects and
> "install" subdirectories manually.  The real beef is having that kind
> of information in a distributed way, so whenever a project is checked
> out or updated, that kind of information, as well as the
> subdirectories themselves, get checked out or updated automagically.

Yes, such information would need to be stored and versioned --- merge_into_dir
seems to be half-way there, but back-porting the changes is difficult.

> Yet another possibility is to have the subsequent propagates that done
> automagically instead of manually, as is done today.  I wonder,
> though, if that's such a smart idea...  It *could* be done through
> some of the hooks, of course...

Automatic updates is not really ideal.

Anthony
-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL





reply via email to

[Prev in Thread] Current Thread [Next in Thread]