I think your suggestion would work fine under some conditions: 1. You always use a top-down design methodology. 2. Your whole repo is a single project.
(1) If you have a bottom-up design (e.g., first design the library, and when you get it working, integrate it into the main app), you’ll never see any build errors until the library itself is ready for integration. Besides, you wouldn’t want to have a working app stopped compiling for no reason only because you’re not ready with the new code yet. (2) Due to the other problem (already mentioned in another thread) of keeping shared code together with projects, I tend to keep all projects that share the same code in a single repo (under different subdirectories, of course). This makes maintenance of shared code a lot easier than if you keep separate repos for each project, and trying to sync the common (shared) code among them. Thanks for your comments. From: Michael Richter Sent: Saturday, June 14, 2014 5:42 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How to deal with incomplete code? I have a goal in my build system that says "commit". That goal tries to do a full build. If it succeeds, it tags my commit with "compiles". If it doesn't succeed it won't commit code and flips me off with an error. Now I have a choice: I can commit anyway with a manual invocation of fossil (for which there are a billion valid reasons), I can branch-on-commit the same way, or I can fix whatever doesn't compile and hit up the commit target again. That way I have a myriad of broken commits, true, but the ones that at least build are flagged as such. On 14 June 2014 22:15, <to...@acm.org> wrote: Hi all, It seems to me that commits are best (from a logical point of view) when they refer to completed work, not for work-in-progress (WIP). Besides, it’s not nice to see a timeline filled with incomplete non-working code. For example, I create a new library code file that is under initial development, but it may take many days/weeks to bring out the initial version, which will become the first commit for this file. After that, each completed/tested update (bug fixes, new features, etc.) will become another commit. But, how do I save the WIP file in the repo in a ‘temporary’ state so that it doesn’t keep track of all incomplete work in the history. You could say, do not add it until it’s completed. Problem 1: Clean would kill it, Problem 2: Working on multiple computers, taking changes along to continue work in other location. Another possible solution is to make a new branch for each new file that is WIP but that still doesn’t seem the best way, let alone after a while the repo will be filled with a whole bunch of temp branches. And what if the new code depends on many of the trunk files? The ‘trunk’ code could be making significant changes (perhaps, some incompatible ones), and the ‘temporary’ branch will have the version of the time the new files started, unless every time ‘trunk’ changes everything is merged into the branch. Besides, making a branch, merging, ... also has the same problem of ‘polluting’ the timeline with unnecessary history. I would like to somehow temporarily store the file in the repo (like with a STASH) but in a way that it will stay there even if I close the repo. Any ideas or suggestions how to deal with this issue? TIA. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------------------------------------------------------------------------- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
