Re: [fossil-users] Question about best practices with Fossil.
Well, I came with one solution of the problem. As long as it can be useful for someone else, I will describe it here. The trick is to use as --baseline the first check-in of the subproject that have unnecessary files striped. For my case, I simply tagged this check-in with OnlyFreshLib tag and now the proper merge sequence for trunk branch becomes following: fossil co trunk fossil merge --baseline OnlyFreshLib FreshLibDev fossil commit Note: The problem in details and the structure of the example repository is described below, in my previous message. -- Original Message -- To: (fossil-users@lists.fossil-scm.org) From: John Found (johnfo...@evrocom.net) Subject: [fossil-users] Question about best practices with Fossil. Date: 3.3.2011 19:22:32 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? If my explanations are not clean enough, you can see the repository at: http://chiselapp.com/user/johnfound/repository/FreshIDE Best Regards http://fresh.flatassembler.net Assembly language visual programming. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users http://fresh.flatassembler.net Assembly language visual programming. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question about best practices with Fossil.
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
