Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation.
That seems like so much more trouble. What am I missing? Is it that people are unaware that they can make edits that are destined to go into a branch before that branch actually exists? Do I need to improve on the documentation? Or does creating the branch first, before making file edits, just fit most peoples mental model better? Are there some advantages to creating branches in advance that I am missing?
Part of the motivation for this question is that, because I never use "fossil branch new" myself, there tend to be more bugs in that command than in the other commands that I use daily. If there is a good reason to do "fossil branch new" then maybe I'll start using it myself and those bugs will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new" - or at least print a warning and ask for confirmation: "Creating branches ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
Richard Hipp <d...@sqlite.org> wrote: > Please help me to understand why people want to > create a new branch before adding changes to that branch, rather than > just waiting until they check-in their edits? I'm not being > sarcastic or critical here. A lot of people do this and I sincerely > want to understand the motivation.
Maybe the way how other DVCS work?
Which DVCS can create branch along with the commit?
Sincerely, Gour
-- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu)
> Change the subject: Please help me to understand why people want to > create a new branch before adding changes to that branch, rather than > just waiting until they check-in their edits?
In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch.
In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with "Now I'm going to start on New Feature X," and since I've just decided that, I may as well make some manifestation of my intention.
I like that both ways are supported, along with the ability to make new branches after the fact.
I often am planning a change or thinking ahead and will create the branch to record my intentions before I've started coding. I do like the ability to checkin changes to a branch but would generally not intentionally use it out of the risk of forgetting that my changes are intended for a branch and then checking them in to the current branch.
Note: It is annoying to me that "fossil branch new foo" won't simply branch from the current node.
By the way, how does "update" differ from "co" in your step 2 below?
On Tue, Aug 9, 2011 at 7:58 AM, Richard Hipp <d...@sqlite.org> wrote: > On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com < > tpero...@compumation.com> wrote:
>> fossil branch new Test 5947928ba****
> Change the subject: Please help me to understand why people want to create > a new branch before adding changes to that branch, rather than just waiting > until they check-in their edits? I'm not being sarcastic or critical here. > A lot of people do this and I sincerely want to understand the motivation.
> That seems like so much more trouble. What am I missing? Is it that > people are unaware that they can make edits that are destined to go into a > branch before that branch actually exists? Do I need to improve on the > documentation? Or does creating the branch first, before making file edits, > just fit most peoples mental model better? Are there some advantages to > creating branches in advance that I am missing?
> Part of the motivation for this question is that, because I never use > "fossil branch new" myself, there tend to be more bugs in that command than > in the other commands that I use daily. If there is a good reason to do > "fossil branch new" then maybe I'll start using it myself and those bugs > will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new" > - or at least print a warning and ask for confirmation: "Creating branches > ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
> Note: It is annoying to me that "fossil branch new foo" won't simply > branch from the current node.
+1
> By the way, how does "update" differ from "co" in your step 2 below?
If you have no edited files, they have the same effect. But if you have some edits that are not yet committed, co will fail unless called with --force, in which case it will overwrite, whereas update will merge your uncommitted changes in to the new branch's files as uncommitted changes.
On Tue, Aug 9, 2011 at 4:58 PM, Richard Hipp <d...@sqlite.org> wrote: > That seems like so much more trouble. What am I missing? Is it that > people are unaware that they can make edits that are destined to go into a > branch before that branch actually
In my experience it's that when i know i've reached a branch point i clean up my trunk, get it comitted, create the branch, and continue work from there. i don't "spontaneously trunk", though i'm sure many do.
> Part of the motivation for this question is that, because I never use > "fossil branch new" myself, there tend to be more bugs in that command than > in the other commands that I use daily. If there is a good reason to do > "fossil branch new" then maybe I'll start using it myself and those bugs > will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new" > - or at least print a warning and ask for confirmation: "Creating branches > ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
i would be really annoyed by such a question - it's a perfect example of software trying to go too far in its assumptions.
Gour-Gadadhara Dasa <g...@atmarama.net> wrote: > > Please help me to understand why people want to > > create a new branch before adding changes to that branch, rather > > than just waiting until they check-in their edits? I'm not being > > sarcastic or critical here. A lot of people do this and I sincerely > > want to understand the motivation.
> Maybe the way how other DVCS work?
> Which DVCS can create branch along with the commit?
Basically any, I presume, which does not overwrite (reset or whatever you call it) local modifications when updating the work tree (work directory) to the new branch's tip. Hence from my personal experience I can say that Git and Subversion allow to do this. _______________________________________________ fossil-users mailing list fossil-us...@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote: > On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com < > tpero...@compumation.com> wrote: > Change the subject: Please help me to understand why people want to create > a new branch before adding changes to that branch, rather than just waiting > until they check-in their edits? I'm not being sarcastic or critical here. > A lot of people do this and I sincerely want to understand the motivation.
We very early discovered the "-b" parameter to "commit", and that's what we use since then, but at our very first use of fossil, we only found "branch new" to create a branch.
So, "branch new" was what we found first. Maybe the documentation about "branch new" could explain about why would someone want to use it, explaining the other possibilities.
Matt Welland <estifo...@gmail.com> wrote: > I often am planning a change or thinking ahead and will create the > branch to record my intentions before I've started coding. I do like > the ability to checkin changes to a branch but would generally not > intentionally use it out of the risk of forgetting that my changes > are intended for a branch and then checking them in to the current > branch.
I'd like to second all written above. This is simply a mental model thing: "oh, these changes I've just made should better be on the new branch" versus "now I want to implement a new feature, so let's fork a new branch now and start coding *on it*". Both are valid on different occasions.
> Note: It is annoying to me that "fossil branch new foo" won't simply > branch from the current node.
Absolutely agreed. I miss Git's `git checkout -b newbranch` encantation which stands for fossil branch new newbranch fossil update newbranch in fossil, which is barely a pleasure to use.
By the way, could it be possible to implement such "I want to start a new branch now" without recording of any new artifacts but instead by just creating some record (in _FOSSIL_, presumably), that the user recorded her intention for the next commit she'll make to start a new branch? That would be more in a fossil's style of managing branches, I feel. _______________________________________________ fossil-users mailing list fossil-us...@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Tue, Aug 09, 2011 at 11:06:23PM +0800, Ambrose Bonnaire-Sergeant wrote: > Personally, this is a habit I bring from git, mainly because I'm not aware > of any other way to doing things.
> I was not aware of fossil commit -branch new-branch, seems like a much > better alternative.
> Half the time I start hacking on something, then "oh, darn I should have > started a branch before I started". This seems much superior.
On Tue, Aug 09, 2011 at 11:27:09AM -0400, Joshua Paine wrote: > On 8/9/2011 11:19 AM, Matt Welland wrote: > > Note: It is annoying to me that "fossil branch new foo" won't simply > > branch from the current node.
> +1
> > By the way, how does "update" differ from "co" in your step 2 below?
> If you have no edited files, they have the same effect. But if you have > some edits that are not yet committed, co will fail unless called with > --force, in which case it will overwrite, whereas update will merge your > uncommitted changes in to the new branch's files as uncommitted changes.
Moreover, 'co' is a much slower operation.
I think of 'update' as: bring my current working directory changes to the check-in I say, considering what I have checked out.
And 'checkout' as: regardless of what I have in my working directory, bring there the files for the named check-in. _______________________________________________ fossil-users mailing list fossil-us...@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote: > On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com < > tpero...@compumation.com> wrote: > (1) fossil branch new new-branch
I forgot to add that I don't like this approach *also* because it does not let me type teh message that will appear in the timeline. So even I wanted to declare some intentions for the time record, I would not use this because I can't type what will appear there.
I agree with the others, I usually start a branch as a part of the process of working on some new feature. It just feels more organized than remembering to decide what branch to use when I finally commit, or changing the branch after the fact.
2011/8/9 Lluís Batlle i Rossell <virik...@gmail.com>
> On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote: > > On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com < > > tpero...@compumation.com> wrote: > > (1) fossil branch new new-branch
> I forgot to add that I don't like this approach *also* because it does not > let > me type teh message that will appear in the timeline. So even I wanted to > declare some intentions for the time record, I would not use this because I > can't type what will appear there.
> That seems like so much more trouble. What am I missing? Is it that people > are unaware that they can make edits that are destined to go into a branch > before that branch actually exists? Do I need to improve on the > documentation? Or does creating the branch first, before making file edits, > just fit most peoples mental model better? Are there some advantages to > creating branches in advance that I am missing?
Besides how older VCSs have worked, many work places have a policy of doing work on branches, then merging the changes, later. By creating the branch first, there is no ambiguity of where new commits will go. _______________________________________________ fossil-users mailing list fossil-us...@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Tue, Aug 9, 2011 at 9:25 AM, Ron Wilson <ronw.m...@gmail.com> wrote: > On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp <d...@sqlite.org> wrote: > > The way I've *always* done things is:
> > That seems like so much more trouble. What am I missing? Is it that > people > > are unaware that they can make edits that are destined to go into a > branch > > before that branch actually exists? Do I need to improve on the > > documentation? Or does creating the branch first, before making file > edits, > > just fit most peoples mental model better? Are there some advantages to > > creating branches in advance that I am missing?
> Besides how older VCSs have worked, many work places have a policy of > doing work on branches, then merging the changes, later. By creating > the branch first, there is no ambiguity of where new commits will go.
This is a good point. For development at work we are setting up git to allow creating branches and limit who can check in on those branches (using gitolite). Pre-creating branches is a hard requirement.
**soapbox mode - feel free to stop reading :) **
The list of things that chip away at making a case for using fossil in serious work (lots of geographically distributed developers with minimal communication channels and a complex project that contains many disparate components) is not long, but does seem unnecessarily limiting:
1. ignores stored in db, no hierarchy, not revision controlled, propagated with sync? - minor but really annoying 2. symlinks not able to be stored (Windows support policy issue) - can route around this one 3. no hooks (Windows support policy issue) - deal breaker 4. mindshare (changing for the better every day but impacted by the above 3)
anything else?
Training time and ramp up on fossil is 100x faster than git and the ticketing, wiki and web is absolutely fantastic but ignore files, symlinks and hooks are basic features available in almost(1) *every* competing scm and IMHO crippling fossil because of limitations of Microsoft Windows seems unnecessary to me.
(1) Symlinks are the arguable exception here but on windows creating a file with the link contents seems a fair fallback.
Just a random and unsolicited $0.02 precipitated by the incredible pain of having to train myself and others on git. Something I'm not even 100% certain I can successfully do for our team :-)
> The list of things that chip away at making a case for using fossil in serious work (lots of geographically distributed developers with minimal communication channels and a complex project that contains many disparate components) is not long, but does seem unnecessarily limiting:
> 1. ignores stored in db, no hierarchy, not revision controlled, propagated with sync? > - minor but really annoying
I had huge problems with settings like ignore-glob, so I have a branch which implements "versionable" settings which are just versioned files in a .fossil-settings directory.
I've been using it for a couple of months. Build the ben-testing branch if you'd like a play. Type "fossil help settings" for instructions. Testing and feedback appreciated!
I'm hoping I can get the ben-testing branch merged at some point. It has a few more useful (to me) changes: SSL client certs, empty-dirs setting, list changes & extras relative to the current working directory.
On Tue, Aug 9, 2011 at 8:35 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote: > On Tue, 9 Aug 2011 08:19:46 -0700 > Matt Welland <estifo...@gmail.com> wrote:
> > I often am planning a change or thinking ahead and will create the > > branch to record my intentions before I've started coding. I do like > > the ability to checkin changes to a branch but would generally not > > intentionally use it out of the risk of forgetting that my changes > > are intended for a branch and then checking them in to the current > > branch. > I'd like to second all written above. > This is simply a mental model thing: "oh, these changes I've just made > should better be on the new branch" versus "now I want to implement a > new feature, so let's fork a new branch now and start coding *on it*". > Both are valid on different occasions.
Does any other VCS have a "commit to <branch>" ability? I know some will let you create a branch and update to it while preserving changes, but that kind of thing always feels like an "oops, I made the changes to the wrong source" type of thing than something planned.
> > Note: It is annoying to me that "fossil branch new foo" won't simply
> > branch from the current node. > Absolutely agreed. > I miss Git's `git checkout -b newbranch` encantation which stands for > fossil branch new newbranch > fossil update newbranch > in fossil, which is barely a pleasure to use.
> By the way, could it be possible to implement such "I want to start a > new branch now" without recording of any new artifacts but instead by > just creating some record (in _FOSSIL_, presumably), that the user > recorded her intention for the next commit she'll make to start a new > branch? That would be more in a fossil's style of managing branches, I > feel.
This is they way mercurial does things. Creating a branch is a local change, and only happens on the repository when you commit those. I'd like it as well - some way of noting that the work in the current checkout is destined for some branch other than the one it's checked out of before I start the work.
Because the Chapter 4.4 in the Fossil Version Control / Users Guide Version 1.7 by Jim Schimpf does it that way.
From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp Sent: Tuesday, August 09, 2011 9:58 AM To: fossil-us...@lists.fossil-scm.org Subject: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com<mailto:tpero...@compumation.com> <tpero...@compumation.com<mailto:tpero...@compumation.com>> wrote:
fossil branch new Test 5947928ba
Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation.
That seems like so much more trouble. What am I missing? Is it that people are unaware that they can make edits that are destined to go into a branch before that branch actually exists? Do I need to improve on the documentation? Or does creating the branch first, before making file edits, just fit most peoples mental model better? Are there some advantages to creating branches in advance that I am missing?
Part of the motivation for this question is that, because I never use "fossil branch new" myself, there tend to be more bugs in that command than in the other commands that I use daily. If there is a good reason to do "fossil branch new" then maybe I'll start using it myself and those bugs will get fixed sooner. Or if not, maybe I'll deprecate "fossil branch new" - or at least print a warning and ask for confirmation: "Creating branches ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N)"
Please explain. Thanks!
-- D. Richard Hipp d...@sqlite.org<mailto:d...@sqlite.org>
-----Original Message----- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Joshua Paine Sent: Tuesday, August 09, 2011 10:10 AM To: fossil-us...@lists.fossil-scm.org Subject: Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
On 8/9/2011 10:58 AM, Richard Hipp wrote: > Change the subject: Please help me to understand why people want to > create a new branch before adding changes to that branch, rather than > just waiting until they check-in their edits?
In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch.
In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with "Now I'm going to start on New Feature X," and since I've just decided that, I may as well make some manifestation of my intention.
I like that both ways are supported, along with the ability to make new branches after the fact.
> -----Original Message----- > From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Joshua Paine > Sent: Tuesday, August 09, 2011 10:10 AM > To: fossil-us...@lists.fossil-scm.org > Subject: Re: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest
> On 8/9/2011 10:58 AM, Richard Hipp wrote: > > Change the subject: Please help me to understand why people want to > > create a new branch before adding changes to that branch, rather than > > just waiting until they check-in their edits?
> In SVN (and possibly others), you have to create the branch first. In Git I still try to make the branch first, because I don't know how to move a commit to a new branch if I forget to add the new branch argument when I commit. The GUI tools I've used for SVN and Git didn't make it easy to put a commit on a new branch.
> In fossil I often just work and worry about branches later, sometimes several commits later, because I know it's really easy to change it. In those cases, I've usually started working on something and realized part way in that I had better branch for this--a totally stress-free realization with fossil. But sometimes I still make the branch first, because sometimes my thought process begins with "Now I'm going to start on New Feature X," and since I've just decided that, I may as well make some manifestation of my intention.
> I like that both ways are supported, along with the ability to make new branches after the fact.
> On Tue, Aug 09, 2011 at 01:01:55PM -0500, tpero...@compumation.com wrote: > > So, how do you move commits in the trunk to a new branch after the fact.
> Open the UI, click the checkin, then edit... and check the part about > "starts a new > branch".
> Regards, > Lluís.
> > -----Original Message----- > > From: fossil-users-boun...@lists.fossil-scm.org [mailto: > fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Joshua Paine > > Sent: Tuesday, August 09, 2011 10:10 AM > > To: fossil-us...@lists.fossil-scm.org > > Subject: Re: [fossil-users] Why do people create branches as a separate > step? Was: Unable to sign manifest
> > On 8/9/2011 10:58 AM, Richard Hipp wrote: > > > Change the subject: Please help me to understand why people want to > > > create a new branch before adding changes to that branch, rather than > > > just waiting until they check-in their edits?
> > In SVN (and possibly others), you have to create the branch first. In Git > I still try to make the branch first, because I don't know how to move a > commit to a new branch if I forget to add the new branch argument when I > commit. The GUI tools I've used for SVN and Git didn't make it easy to put a > commit on a new branch.
> > In fossil I often just work and worry about branches later, sometimes > several commits later, because I know it's really easy to change it. In > those cases, I've usually started working on something and realized part way > in that I had better branch for this--a totally stress-free realization with > fossil. But sometimes I still make the branch first, because sometimes my > thought process begins with "Now I'm going to start on New Feature X," and > since I've just decided that, I may as well make some manifestation of my > intention.
> > I like that both ways are supported, along with the ability to make new > branches after the fact.
> 2011/8/9 Lluís Batlle i Rossell <virik...@gmail.com>
> > On Tue, Aug 09, 2011 at 01:01:55PM -0500, tpero...@compumation.com wrote: > > > So, how do you move commits in the trunk to a new branch after the fact.
> > Open the UI, click the checkin, then edit... and check the part about > > "starts a new > > branch".
> > Regards, > > Lluís.
> > > -----Original Message----- > > > From: fossil-users-boun...@lists.fossil-scm.org [mailto: > > fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Joshua Paine > > > Sent: Tuesday, August 09, 2011 10:10 AM > > > To: fossil-us...@lists.fossil-scm.org > > > Subject: Re: [fossil-users] Why do people create branches as a separate > > step? Was: Unable to sign manifest
> > > On 8/9/2011 10:58 AM, Richard Hipp wrote: > > > > Change the subject: Please help me to understand why people want to > > > > create a new branch before adding changes to that branch, rather than > > > > just waiting until they check-in their edits?
> > > In SVN (and possibly others), you have to create the branch first. In Git > > I still try to make the branch first, because I don't know how to move a > > commit to a new branch if I forget to add the new branch argument when I > > commit. The GUI tools I've used for SVN and Git didn't make it easy to put a > > commit on a new branch.
> > > In fossil I often just work and worry about branches later, sometimes > > several commits later, because I know it's really easy to change it. In > > those cases, I've usually started working on something and realized part way > > in that I had better branch for this--a totally stress-free realization with > > fossil. But sometimes I still make the branch first, because sometimes my > > thought process begins with "Now I'm going to start on New Feature X," and > > since I've just decided that, I may as well make some manifestation of my > > intention.
> > > I like that both ways are supported, along with the ability to make new > > branches after the fact.
On Tue, 9 Aug 2011, Richard Hipp wrote: > Change the subject: Please help me to understand why people want to create a new branch before adding > changes to that branch, rather than just waiting until they check-in their edits? I'm not being > sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation.
If you create the branch first you cannot forget later and commit to the wrong branch. It avoids operator error later on. If you need to edit a file and save your changes to a copy you may do the same:
- open the file - use the 'save as' command to change the name - edit for 30 minutes - use the 'save' command.
If you could just tell fossil that you intend to commit to a new branch from the current workspace/checkout creating that extra commit object could be avoided without risking a commit to the wrong branch.
$ fossil open ~/repos/mrcoffee.fossil $ fossil branch next espresso-feature .... much later .... $ fossil commit Commit to new branch 'espresso-feature'? (y/N)
