Well, maybe my ideas are wrong for you, but I assure you, to me they always
seem very right! :) Just like programming styles, mine *may* be very wrong to
many, but it's the best there is to me, and has never let me down!
But at least we agree on committing those work-in-progress files on some
branch, other than trunk, to be eventually merged in the main trunk. OK, my
problem is not so much with the committing act per se (of non-working code,) --
besides, you do have to have a mechanism of adding your changes, even WIP ones,
in the repo -- it's with ending up with a history / timeline that is full of
'incomplete attempts', instead of clean code commits, and (for now, at least)
no way to filter by, say, tag, so you have to see every little silly
modification to any (yet) useless file. If you could filter by tag, for
example, or if you could, by default, see the timeline of only the currently
active branch, it would be very good, as all those 'noise' changes would
disappear.
As for your example, there's nothing new about it. Of course, you can put
anything anywhere and mark it with an appropriate comment, and feel happy about
it. But, imagine ten thousand commits later, where only 1% is working code,
and the rest is temporary garbage that not only doesn't even compile in its
entirety but may also never be incorporated into working code. Isn't it
frustrating to look at such a long timeline with very little good value? It is
to me!
Thanks for your comments, anyway!
P.S. to the ‘often opposing’ list.
(Hmm, maybe I subconsciously have a way to bring out the ‘evil’ in people!)
Look, I'm not on this list to get popularity votes, I'm only writing to either
figure out ways how to do my work better – granted, the way *I* define 'better'
– or to 'complain' on hopefully accepting ears, about things that I feel need
improving. Maybe I’m often the only one facing certain problems because of how
I organize my work. In that case, I don’t expect anyone’s sympathy for my very
unique problems. In that case, I would probably spend less time if I wrote my
own SCM system than trying to improve the existing one by convincing everyone
else about the necessities I see. Hey, why not, I’ve done it before with
compilers, assemblers, and MCU operating systems that didn’t work they way I
expected them, and I couldn’t ‘bring’ the ones available closer to my needs. I
suppose that’s the same reason there are as many different SCMs – too many
conflicting opinions.
But my own approach has been different, and I thought I wasn’t so ‘unique’ in
that, as well! Some of my work became publically available for free, and as a
result I got many requests over the years from random users, which I felt I had
a ‘moral’ obligation to at least consider, and so I accepted (and in most cases
implemented – actually always, except when there was an unquestionable conflict
with or misunderstanding of existing features) everyone’s ideas for improvement
even when I felt those were not something that affected my own work or
programming style, and knowing I would be the one to do all the programming for
them. But, you know what? In the end, I had a much better product for myself,
too!
Don’t get me wrong, FOSSIL is admittedly a great piece of software (and many
thanks are due to its main authors), but it still has many shortcomings when
used in ways other than envisioned. I often get the impression, however, some
would like [me], instead of talking about what seems wrong, to start writing
how FOSSIL is so great, and please don't improve anything besides bugs because
there's always a group of people who will be bothered by any change (even
though most of the time it doesn't even directly affect them – they simply
‘resist change’ – psychology 101), and things are fine they way they are!
BTW, I didn’t voice my position on the ‘no initial empty commit’ issue,
although I strongly felt it was a genuine waste of programming effort, with a
high risk of ‘bug-gage’. But, at the same time, I accepted the possibility for
this issue being important to others, so it’s none of my business to try to
‘block’ it. I do appreciate the work of all those involved in maintaining any
piece of software, be it open source, or commercial, but I also think if you’re
not interested in opinions from those not directly involved in the programming
effort, then maybe it should be a closed project dedicated solely to those who
contribute code to it.
In conclusion, I’ll let you all draw your own conclusions, and try to agree on
them! :)
-----Original Message-----
From: John Found
Sent: Sunday, June 15, 2014 9:54 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] How to deal with incomplete code?
I think you are wrong with your ideas. Committing not working code is not a bad
practice at all. Commit often, commit always. I am committing not working code
all the time and it works great for me. :)
I am only trying to keep the trunk branch working (notice: only "trying").
Create new branch for every feature you want to experiment and when it is
ready, simply merge it with the trunk.
You can see how it look in practice, on one of my repositories:
http://fresh.flatassembler.net/fossil/repo/fresh/timeline
You can see for example: 2014-06-14:
[42504ecb33] Leaf: Partially fixed (compiles, but not working properly)
TScrollWindow and TFreshEdit. (user: johnfound, tags: FreshLibGUI)
On Sat, 14 Jun 2014 17:15:12 +0300
<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.
--
asm32.info <johnfo...@asm32.info>
_______________________________________________
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
