Re: [fossil-users] How to do branching with new major versions

[Ron W]

On Thu, Sep 11, 2014 at 12:09 PM, Nico Williams 
wrote:

> On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp  wrote:
> > On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams 
> > wrote:
> >>
> >> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp 
> >> > On the few cases when this has happened to me, I've moved "goof" into
> a
> >> > new
> >> > branch (typically "mistake") then cherry pick the follow-on check-ins
> >> > back
> >> > over to trunk, assuming there are not to many of them.
> >>
> >> Eh??  That's rebasing!  ;)  (really)
> >
> > Except that the original sequence of changes is preserved in the tree,
> not
> > discarded at the next GC.  That's an important difference.
>
> Right, and I very much agree with that.  But you're doing this without
> first-class support for rebase; it's a very manual process :(


I would call Richard's procedure "move with iterated reverse merging".

Although I would generally support automation, I would still want to test
the result of each merge before committing and continuing.

That said, I wonder if git's rebase command makes rebasing too easy.
___
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] How to do branching with new major versions

[Nico Williams]

On Thu, Sep 11, 2014 at 11:01 AM, Richard Hipp  wrote:
> On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams 
> wrote:
>>
>> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp 
>> > On the few cases when this has happened to me, I've moved "goof" into a
>> > new
>> > branch (typically "mistake") then cherry pick the follow-on check-ins
>> > back
>> > over to trunk, assuming there are not to many of them.
>>
>> Eh??  That's rebasing!  ;)  (really)
>
> Except that the original sequence of changes is preserved in the tree, not
> discarded at the next GC.  That's an important difference.

Right, and I very much agree with that.  But you're doing this without
first-class support for rebase; it's a very manual process :(
___
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] How to do branching with new major versions

[Richard Hipp]

On Thu, Sep 11, 2014 at 11:50 AM, Nico Williams 
wrote:

> On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp 
> > On the few cases when this has happened to me, I've moved "goof" into a
> new
> > branch (typically "mistake") then cherry pick the follow-on check-ins
> back
> > over to trunk, assuming there are not to many of them.
>
> Eh??  That's rebasing!  ;)  (really)
>

Except that the original sequence of changes is preserved in the tree, not
discarded at the next GC.  That's an important difference.

-- 
D. Richard Hipp
d...@sqlite.org
___
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] How to do branching with new major versions

[Nico Williams]

On Wed, Sep 10, 2014 at 10:47 PM, Richard Hipp  wrote:
> On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland  wrote:
>> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp  wrote:
>>> Sometimes we will make a check-in to trunk then later decide it doesn't
>>> belong there, so then move it into a branch.  (
>>
>> Isn't this only possible if no further commits have been made on the
>> trunk? I suppose one possible "fix" if there have been additional commits is
>> to reverse cherrypick out the change but that leaves the timeline without a
>> clear visible trace of the actions. A similar option would be to cherrypick
>> the post-goof commits to a new trunk and rename the goof + downstream
>> commits as branch "goof" and then close (and maybe hide) it. Do you have a
>> better way to do this?
>
> On the few cases when this has happened to me, I've moved "goof" into a new
> branch (typically "mistake") then cherry pick the follow-on check-ins back
> over to trunk, assuming there are not to many of them.

Eh??  That's rebasing!  ;)  (really)

More seriously, rebasing the upstream generally means that downstreams
need some instructions on how to recover.  I've been thinking that
 ought to have an
option to record in a merge-like commit what has been done in a rebase
operation.  Something like a commit with subject "Rebase", the rebase
script in the message body, and, crucially, two parent commits listed:
the pre-rebase head commit, and the base commit for the rebase.  This
would provide everything a downstream needs to recover, and it would
record what happened.  And it would retain live references to dead
branches, thus preventing garbage collection commits that would not be
reachable but for Rebase commits.  I wonder if something like that
could make rebase more acceptable as a concept elsewhere than git.

Nico
--
___
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] How to do branching with new major versions

[Matt Welland]

On Wed, Sep 10, 2014 at 8:47 PM, Richard Hipp  wrote:

>
>
> On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland 
> wrote:
>
>>
>> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp  wrote:
>>
>>> Sometimes we will make a check-in to trunk then later decide it doesn't
>>> belong there, so then move it into a branch.  (
>>
>>
>> Isn't this only possible if no further commits have been made on the
>> trunk? I suppose one possible "fix" if there have been additional commits
>> is to reverse cherrypick out the change but that leaves the timeline
>> without a clear visible trace of the actions. A similar option would be to
>> cherrypick the post-goof commits to a new trunk and rename the goof +
>> downstream commits as branch "goof" and then close (and maybe hide) it. Do
>> you have a better way to do this?
>>
>
> On the few cases when this has happened to me, I've moved "goof" into a
> new branch (typically "mistake") then cherry pick the follow-on check-ins
> back over to trunk, assuming there are not to many of them.
>

On reflection I agree this is a good approach.

This type of thing has caused some confusion for my team in that when the
>> branch of the current checkout node changes fossil does not inform the
>> user. In the example a user might find themselves mysteriously on branch
>> "goof" after doing "fossil update" where previously the branch was "trunk".
>> The fix is to run "fossil up trunk" but that is tribal knowledge and
>> non-obvious. A message from fossil when the branch changes in this scenario
>> would be good IMHO.
>>
>
> I have your request.
>

Thank you for considering it.


> --
> D. Richard Hipp
> d...@sqlite.org
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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] How to do branching with new major versions

[Richard Hipp]

On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland  wrote:

>
> On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp  wrote:
>
>> Sometimes we will make a check-in to trunk then later decide it doesn't
>> belong there, so then move it into a branch.  (
>
>
> Isn't this only possible if no further commits have been made on the
> trunk? I suppose one possible "fix" if there have been additional commits
> is to reverse cherrypick out the change but that leaves the timeline
> without a clear visible trace of the actions. A similar option would be to
> cherrypick the post-goof commits to a new trunk and rename the goof +
> downstream commits as branch "goof" and then close (and maybe hide) it. Do
> you have a better way to do this?
>

On the few cases when this has happened to me, I've moved "goof" into a new
branch (typically "mistake") then cherry pick the follow-on check-ins back
over to trunk, assuming there are not to many of them.


>
> This type of thing has caused some confusion for my team in that when the
> branch of the current checkout node changes fossil does not inform the
> user. In the example a user might find themselves mysteriously on branch
> "goof" after doing "fossil update" where previously the branch was "trunk".
> The fix is to run "fossil up trunk" but that is tribal knowledge and
> non-obvious. A message from fossil when the branch changes in this scenario
> would be good IMHO.
>

I have your request.
-- 
D. Richard Hipp
d...@sqlite.org
___
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] How to do branching with new major versions

[Matt Welland]

On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp  wrote:

> Sometimes we will make a check-in to trunk then later decide it doesn't
> belong there, so then move it into a branch.  (


Isn't this only possible if no further commits have been made on the trunk?
I suppose one possible "fix" if there have been additional commits is to
reverse cherrypick out the change but that leaves the timeline without a
clear visible trace of the actions. A similar option would be to cherrypick
the post-goof commits to a new trunk and rename the goof + downstream
commits as branch "goof" and then close (and maybe hide) it. Do you have a
better way to do this?

This type of thing has caused some confusion for my team in that when the
branch of the current checkout node changes fossil does not inform the
user. In the example a user might find themselves mysteriously on branch
"goof" after doing "fossil update" where previously the branch was "trunk".
The fix is to run "fossil up trunk" but that is tribal knowledge and
non-obvious. A message from fossil when the branch changes in this scenario
would be good IMHO.
-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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] How to do branching with new major versions

[Philip Bennefall]

Thanks, Richard! I really appreciate the detailed response. Many of the 
practices you describe, I am already following such as tagging each 
release with both release and the version number. It makes things really 
easy when going back to fix bugs, answer support queries about the given 
version etc. The idea about putting patched releases in a new branch 
based on the original release is neat, too. I will start doing that.


Digging around in the Fossil UI I found out how to do exactly what I 
wanted, as well. I can rename branches easily and I can move check-ins 
between branches with no difficulty. Thanks once again, for making the 
system so intuitive!


Kind regards,

Philip Bennefall
P.S. You might be interested to know that Fossil has one of the most 
accessible web interfaces for blind/visually impaired users with screen 
reading software, out of all the version control systems I have used.

On 9/11/2014 2:12 AM, Richard Hipp wrote:



On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall > wrote:


Hi all,

I have a question about how to properly use branches in the
following scenario:

I have version 1.0 of my software, which is stable. Then I want to
start developing version 2. Initially I make a version2 branch
where all development happens, while at the same time I continue
to maintain trunk which is currently version 1.


This is what we do on SQLite:

(1) We try to keep the trunk always working.  (This helps when doing 
bisect in later years.)  New development goes on feature branches 
until (a) we know it is going to be merged into a release, and (b) it 
passes all tests. Then it gets merged into trunk.  A recent example of 
a feature branch is "btree-speedup" 
(http://www.sqlite.org/src/timeline?r=btree-speedup). Or changes can 
be made directly on trunk as long as they pass all tests and do not 
seem risky or disruptive.


As I write this, we are working on three separate feature branchs:  
user-auth, 64-bit-lengths, and experimental-bulk-update.


(2) Release is from trunk.  We just --tag a trunk check-in with 
"release" and with "version-X.Y.Z".  We also set --bgcolor 'xd0c0ff' 
so that releases have a distinct background color.


(3) New development after the release continues to go onto trunk (once 
it passes tests as required by [1] above).  If we need to patch a 
release, then the patches go into a branch rooted at the release.  The 
branch for version-X.Y.Z is named "branch-X.Y.Z".   Example: 
http://www.sqlite.org/src/timeline?r=branch-3.8.4


(4) We also maintain a few long-term branches in parallel with trunk.  
These are versions of SQLite that we have no immediate plans to merge 
into trunk but need to track trunk.  The current long-term branches 
are "apple-osx" (containing the slightly-modified code that gets 
shipped with MacOS and iOS) and "sessions".  Up unto just recently, we 
were also maintaining the "threads" branch, but it has now been merged 
into trunk.


Sometimes we will make a check-in to trunk then later decide it 
doesn't belong there, so then move it into a branch.  (You can do that 
easily in Fossil.)  An example is the "btree-speedup" changes which 
started on trunk but got move to a branch.  See the timeline at 
http://www.sqlite.org/src/timeline?c=2014-08-20 and specifically the 
edit at 13:11 for when the original trunk check-in was moved into the 
"btree-speedup" branch.



--
D. Richard Hipp
d...@sqlite.org 


___
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] How to do branching with new major versions

[Richard Hipp]

On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall 
wrote:

> Hi all,
>
> I have a question about how to properly use branches in the following
> scenario:
>
> I have version 1.0 of my software, which is stable. Then I want to start
> developing version 2. Initially I make a version2 branch where all
> development happens, while at the same time I continue to maintain trunk
> which is currently version 1.
>

This is what we do on SQLite:

(1) We try to keep the trunk always working.  (This helps when doing bisect
in later years.)  New development goes on feature branches until (a) we
know it is going to be merged into a release, and (b) it passes all tests.
Then it gets merged into trunk.  A recent example of a feature branch is
"btree-speedup" (http://www.sqlite.org/src/timeline?r=btree-speedup).  Or
changes can be made directly on trunk as long as they pass all tests and do
not seem risky or disruptive.

As I write this, we are working on three separate feature branchs:
user-auth, 64-bit-lengths, and experimental-bulk-update.

(2) Release is from trunk.  We just --tag a trunk check-in with "release"
and with "version-X.Y.Z".  We also set --bgcolor 'xd0c0ff' so that releases
have a distinct background color.

(3) New development after the release continues to go onto trunk (once it
passes tests as required by [1] above).  If we need to patch a release,
then the patches go into a branch rooted at the release.  The branch for
version-X.Y.Z is named "branch-X.Y.Z".   Example:
http://www.sqlite.org/src/timeline?r=branch-3.8.4

(4) We also maintain a few long-term branches in parallel with trunk.
These are versions of SQLite that we have no immediate plans to merge into
trunk but need to track trunk.  The current long-term branches are
"apple-osx" (containing the slightly-modified code that gets shipped with
MacOS and iOS) and "sessions".  Up unto just recently, we were also
maintaining the "threads" branch, but it has now been merged into trunk.

Sometimes we will make a check-in to trunk then later decide it doesn't
belong there, so then move it into a branch.  (You can do that easily in
Fossil.)  An example is the "btree-speedup" changes which started on trunk
but got move to a branch.  See the timeline at
http://www.sqlite.org/src/timeline?c=2014-08-20 and specifically the edit
at 13:11 for when the original trunk check-in was moved into the
"btree-speedup" branch.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users