Re: [fossil-users] Merge question

[Stephan Beal]

On Mon, Sep 25, 2017 at 5:32 PM, Andy Goth  wrote:

> whatever was going on.  Might want to explicitly turn on more warnings
> like -Wunused or -Wall or even -Wextra to help spot these types of issues.)
>

Sidebar: i tried -Wall with fossil years ago but it didn't like sqlite3's
use of "long long", which isn't C89 (i'm not even sure it's C99, but it's
apparently supported by all compilers).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Merge question

[Andy Goth]

On 09/25/17 10:39, Richard Hipp wrote:

On 9/25/17, Andy Goth  wrote:


As far as I can tell, in the general case I described in my previous
email, assuming waiting was not an option, the best to do would have
been to explicitly specify the -baseline option when merging the child
branch and later when merging its parent branch.  But this MUST be done
in combination with additional testing to confirm that the child branch
wasn't actually dependent on anything in its parent branch.  And of
course the final merge also must be tested to confirm it didn't leave
anything out due to -baseline being forgotten or mistyped.  Thoughts?


I was thinking of changing --baseline so that it records the merge
baseline using a Q card instead of a P card, as if the merge were a
cherrypick.


Not a bad idea at all.  This avoids the second part of the problem quite 
nicely.  If I recall correctly, the Q card supports listing a range of 
merged check-ins even though this feature is never actually used in 
practice.


As for the user desire that a merge arrow be shown, I feel this would 
best be addressed by showing cherrypick and backout merges.  I wrote up 
this wishlist item eons ago but never got around to working on it.  Does 
anyone have any new ideas about this?


How should such alternative merge arrows be rendered?  Colors?  Can 
dashed lines be shown?  Can the arrowhead be a symbol such as a tiny 
circle or an X?


--
Andy Goth | 
___
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] Merge question

[Richard Hipp]

On 9/25/17, Andy Goth  wrote:

> As far as I can tell, in the general case I described in my previous
> email, assuming waiting was not an option, the best to do would have
> been to explicitly specify the -baseline option when merging the child
> branch and later when merging its parent branch.  But this MUST be done
> in combination with additional testing to confirm that the child branch
> wasn't actually dependent on anything in its parent branch.  And of
> course the final merge also must be tested to confirm it didn't leave
> anything out due to -baseline being forgotten or mistyped.  Thoughts?

I was thinking of changing --baseline so that it records the merge
baseline using a Q card instead of a P card, as if the merge were a
cherrypick.

-- 
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] Merge question

[Andy Goth]

On 09/25/17 10:18, Richard Hipp wrote:

On 9/25/17, Andy Goth  wrote:

In response to Chris Rydalch saying that search-technote works for him,
in combination with it passing all my tests, I'd like to merge it to trunk.

What is the correct procedure for doing so?

At this point I'm inclined to just be patient and let
annotation-enhancements be merged first.  That would solve everything.


Merged now.


Thank you for your testing and your corrections.  I don't have access to 
any Ubuntu systems, so I didn't spot the original problem you came 
across.  (No clue why Ubuntu has -Werror on by default, or whatever was 
going on.  Might want to explicitly turn on more warnings like -Wunused 
or -Wall or even -Wextra to help spot these types of issues.)


As far as I can tell, in the general case I described in my previous 
email, assuming waiting was not an option, the best to do would have 
been to explicitly specify the -baseline option when merging the child 
branch and later when merging its parent branch.  But this MUST be done 
in combination with additional testing to confirm that the child branch 
wasn't actually dependent on anything in its parent branch.  And of 
course the final merge also must be tested to confirm it didn't leave 
anything out due to -baseline being forgotten or mistyped.  Thoughts?


--
Andy Goth | 
___
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] Merge question

[Richard Hipp]

On 9/25/17, Andy Goth  wrote:
> In response to Chris Rydalch saying that search-technote works for him,
> in combination with it passing all my tests, I'd like to merge it to trunk.
>
> What is the correct procedure for doing so?
>
> At this point I'm inclined to just be patient and let
> annotation-enhancements be merged first.  That would solve everything.
>

Merged now.

-- 
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

[fossil-users] Merge question

[Andy Goth]

In response to Chris Rydalch saying that search-technote works for him, 
in combination with it passing all my tests, I'd like to merge it to trunk.


What is the correct procedure for doing so?

If I do:

$ f up trunk
$ f merge search-technote -baseline root:search-technote -integrate

Then any future merge of annotation-enhancements will omit all changes 
made 2017-09-23 because the merge record will show that they were 
already merged due to being in the baseline of search-technote.  To 
correct, said future merge would have to explicitly use the -baseline 
root:annotation-enhancements option.


Instead I could cherrypick each of the five check-ins comprising the 
search-technote branch.  This would avoid the aforementioned problem 
but, in addition to being a pain in the butt to do, would also not put a 
merge arrow in the graph.  Of course, while said merge arrow is nice to 
see, its existence is responsible for said problem.


A third approach would be to construct an alternative 
annotation-enhancements branch made by cherrypicking each of the 
search-technote check-ins, but this new branch would be rooted on trunk. 
 Then merge that branch and be done.


What's the best way to handle this situation?

While on this subject, there are also a number of other changes on the 
annotation-enhancements branch that are unrelated to annotations.  What 
do we do with them?


At this point I'm inclined to just be patient and let 
annotation-enhancements be merged first.  That would solve everything.


Yet, my question remains.  What is the best way to handle merging a 
branch-to-a-branch back to trunk without immediately incorporating 
unrelated branch changes while still allowing said changes to be 
incorporated when the branch is later merged?


--
Andy Goth | 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Merge question

[Zoltán Kócsi]

Consider the following scenario:

Let's say I have two branches of a project, a version A and a version B
of a product (for example, they go to two different markets with
slightly different requirements or some other reason) but of course A
and B share a lot of common stuff. Or we can have a release branch
where only bugfixes are done and a development branch with all sorts
of new features but not guaranteed to work stuff. It doesn't matter
much why we have two active branches, but we do. What matter is this:

While working on 'A' I find a better implementation for a module, which
consists of a handful of code and header files and is used by both
branches. I therefore re-write the entire module, implementing the new
superior algorithm, test it and indeed it is a Good Thing.

Then I'd like to apply the same changes on the 'B' branch as well, for
obvious reasons. I can't merge the two branches, as they really are
separate versions, rather, I want to merge *only* that particular set
of files of the A branch to the B branch.

Is there a way to do that? That is, merge only a bunch of files
between two branches but leave everything else untouched on both
branches (and of course still having two branches)? Note that there
already are all sorts of differences between the branches, not just the
files of the re-written module.

I can of course check out one branch in one directory and the other in
an other, hand-copy the files from A to B and then check-in B to the
common repository, but that seems to be a very stone-age solution and
defeating the purpose of having a database that keeps track of all the
relationships between files and branches and versions.

Any advice would be most welcome.

Thanks,

Zoltan
___
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] Merge question

[Richard Hipp]

On 4/15/15, Zoltán Kócsi zol...@bendor.com.au wrote:
 I want to merge *only* that particular set
 of files of the A branch to the B branch.

 Is there a way to do that?

There are several ways to do this.

Probably the best way is to designate one branch as the main branch.
(Let's call it A.)  And let all other branch derive from A.  All
global changes (changes that should be common to all branches) are
applied to A.  Then periodically merge A-B, A-C, A-D, and so forth.
This is the usual approach taken at SQLite.  The main branch is
trunk.  But we also continuously support various derived branches:
apple-osx, ota-update, and sessions.  New or radically altered code
that is common to all four branches goes onto trunk, then we merge
trunk to the others on a periodic basis.

The other thing you can do is a partial merge from A to B.  First do
a regular full merge:  fossil up B; fossil merge A.  This brings
over why more changes than you want, however.  So then revert the
files that you do not want to merge.  fossil revert file1.c file2.c
  Then test and commit.  I just did this for a branch on SQLite:
https://www.sqlite.org/src/info/b8768f124ef7d79e

Finally, you could just manually make the same changes in B that you
made in A.  The fossil artifact command can be used to quickly pull
over new versions of files.
-- 
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] Merge question

[Andy Bradford]

Thus said =?UTF-8?B?Wm9sdMOhbiBLw7Njc2k=?= on Thu, 16 Apr 2015 00:16:11 +1000:

 Is  there a  way to  do that?  That is,  merge only  a bunch  of files
 between  two branches  but  leave everything  else  untouched on  both
 branches (and  of course still  having two branches)? Note  that there
 already are  all sorts of  differences between the branches,  not just
 the files of the re-written module.

I don't know  of a way to  merge just a subselection  of files, however,
you can merge just a subselection  of the checkins made while developing
the new module using the --cherrypick option to ``fossil merge.''

http://www.fossil-scm.org/index.html/help?cmd=merge

Andy
-- 
TAI64 timestamp: 4000552e79ca


___
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] Merge question

[tonyp]

I think what you're looking for is to simply copy a file from one branch to 
another.


The way I often do this is to use the update command to bring in those files 
(usually one or very few files) from whatever other branch (any check-in 
really -- even from same branch, older version).

No need to use the merge command for this, in my view.

-Original Message- 
From: Zoltán Kócsi

Sent: Wednesday, April 15, 2015 5:16 PM
To: Fossil SCM user's discussion
Subject: [fossil-users] Merge question

Is there a way to do that? That is, merge only a bunch of files
between two branches but leave everything else untouched on both
branches (and of course still having two branches)? Note that there
already are all sorts of differences between the branches, not just the
files of the re-written module.

Zoltan

___
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] Merge question

[Zoltán Kócsi]

Thanks for all the answers.

Zoltan
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users