On Thu, 3 Mar 2011 19:22:32 +0200 "John Found" <johnfo...@evrocom.net> wrote:
> I am really beginer in the world of version control and project > management. Recently I created a repository for one of my projects. > This repository contains the project "Fresh" that consists of two > relatively independent projects "FreshIDE" and "FreshLib". "FreshLib" > is actually part of FreshIDE, but can exists as a stand alone product > as well. So, I created several brances that to make development easy. > One of these is "FreshLibDev" where I deleted all files from trunk, > but the files of FreshLib itself. > > But now I have a small problem. When I change the files in > FreshLibDev I want these changes to be applied to the FreshIDE branch > (I mean trunk). When I try it with "fossil merge FreshLib" from the > trunk, fossil tries to delete all files from the trunk, but FreshLib > files. "--cherrypick" helps little, because it updates only part of > the files. (and I still can't understand which files it updates ;) ) > Now I do the job, using "fossil update FreshLibDev freshlib/*" but > this update is not displayed on the timeline graphic tree, and > obstructs the comfort following of the changes. > > So, at the end the question: What are the best practices to do such > things in fossil and what I messed up with the project management? I think in your case I would just create two top-level directories -- one for the library and another one for the IDE using that library, populate them, create a check-in and then fork the desired branches -- one for the library and another one for the IDE. While working on one branch or another, just do not touch the directory of a "foreign" project. In this case, merges between these branches should be guaranteed to succeed as they won't have any conflicts by definition. The only problem with this approach is exporting data: `fossil zip` will export both directories and if you want to package them separately, you'd have to repack the resulting archive. On the other hand, I do not really see fit in defining branches in the way you envisioned. Since these two projects seems to be tightly related, it appears to me that using "feature branches" would be a more convenient approach: fork a branch when you need to implement a feature, change both the library and the IDE files in it, then merge it to the mainline (let be "trunk", the default branch, for instance). _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
