Merging 3rd party updates which are not in a repository into my?repository

[doahh]

This sounds like a great idea but there are a couple of things I don't
understand:

1) Why the intricacy with the symlink? Is it not just the same as creating
an empty repo, adding the files for version 1.1 (tag it), then adding the
files for 2.1 with -s 70 (tag it again)?

2) When you do a pull from the mvnforum-incoming to the myapp repo, do you
not get problems as the repositories are unrelated? I though I had tried
doing something like that and couldn't but maybe my problem was caused by
something else.




Pierre Asselin-2 wrote:
> 
> doahh <gavin at prodia.co.uk> wrote:
> 
>> I have a web application that uses a MVNForum. My app uses mvnforum 1.1
>> and
>> I have made modifications to it in order for it to have tighter
>> integration
>> with my app. MVNForum has now had a bug fix/security/upgrade release that
>> I
>> would like to merge into my app. Currently my forum project contains only
>> the files from mvnforum that I have modified.
> 
> What if you could maintain an "mvnforum-incoming" hg repository
> with the MVNForum releases and only the MVNForum releases ?  Then
> you could clone and pull from that repository as if it were published
> by the MVNForum people.  How you maintain your variants is "just"
> normal Mercurial workflow and I don't want to get into that here :-)
> 
> Anyway, here's the idiosyncratic solution I came up with.
> It relies on Mercurial implementation details but I floated
> the idea in this list before and didn't get flamed.  (If
> what I propose is dangerous I hope somebody will speak up.)
> 
> Create an empty repo.
> 
>     hg init mvnforum-incoming
> 
> Code drop:
> 
>     cd /anywhere/you/like
>     tar xjvf mvnforum-1.1.tar.bz2
>     cd mvnforum-1.1
>     ln -s /path/to/mvnforum-incoming/.hg .hg
>     hg addremove --similarity 70
>     hg commit --message 'MVNForum 1.1'
>     cd ..
>     rm -rf mvnforum-1.1
> 
> All code drops are done the same way.  The mvnforum-incoming
> repository holds a linear sequence of clean releases (initially
> empty) and is always at the tip of said sequence (but no files
> are checked out).  Planting the .hg symlink in a freshly unpacked
> tarball turns it into a Mercurial sandbox with modified, added
> and removed files, which can be committed as the new tip once
> you've figured out the file renames.
> 
> The symlink trick is POSIX.  On Windows I guess you would
> drag-and-drop the .hg subfolder under the tarball and
> drag-and-drop it back after the commit (all under the
> same drive letter so the DND is a move, not a copy).
> 
> Good luck.
> 
> -- 
> pa at panix dot com
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
> 
> 

-- 
View this message in context: http://www.nabble.com/Merging-3rd-party-updates-which-are-not-in-a-repository-into-my-repository-tp21729193p21774782.html
Sent from the Mercurial mailing list archive at Nabble.com.