Private branches? I don't know, I'll give that a try.
Thanks for your suggestion.
Questions (to all):
1. If the only way is to use a special branch to do what I need, can at
least a single branch be reused multiple times? I mean the same branch name
(e.g., the WIP branch) to be created, closed, recreated, re-closed,
continuously. That way, I will not end up with myriads of test branches in
the FOSSIL BR LS command.
2. Can a branch contain only the single incomplete file I'm working on, but
somehow to 'load' this branch together with the 'trunk'? I.e., I want to
have all the files of the current trunk plus the single (or few) file(s) of
my special WIP branch. Is this possible? If yes, how?
TIA
-----Original Message-----
From: Michai Ramakers
Sent: Saturday, June 14, 2014 5:23 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How to deal with incomplete code?
Hello,
On 14 June 2014 16:15, <to...@acm.org> wrote:
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?
This does not answer your question - since you already mentioned it
yourself, but I'd simply choose a branch, where the timeline actually
shows the truth of what happens/happened during development, even for
potential dead ends. Perhaps private branches would work for you
(http://www.fossil-scm.org/index.html/doc/tip/www/private.wiki)
although I have no experience with them.
Michai
_______________________________________________
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
