[fossil-users] Warnings on no common ancestor
Hello, I had troubles in a big merge of hundreds of files, where five filse had a message like this: fossil: WARNING - no common ancestor: ... I did not notice them along the list of files, because the final abstract of merge conflicts does not include them. Additionally, "fossil merge -n | grep" will not find them, because they appear at stderr. I'd prefer those 'no common ancestor' to appear somehow at the final abstract, maybe counting as merge conflicts. What do you think? Now I've to investigate why I have a 'no common ancestor case', because I think this should not have happened. Regards, Lluís ___ 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] Warnings on no common ancestor
> Additionally, "fossil merge -n | grep" will not find them, because they appear > at stderr. What about?: fossil merge -n |& grep RR El 10 de febrer de 2012 10:30, Lluís Batlle i Rossell ha escrit: > Hello, > > I had troubles in a big merge of hundreds of files, where five filse had a > message like this: > fossil: WARNING - no common ancestor: ... > > I did not notice them along the list of files, because the final abstract of > merge conflicts does not include them. > > Additionally, "fossil merge -n | grep" will not find them, because they appear > at stderr. > > I'd prefer those 'no common ancestor' to appear somehow at the final abstract, > maybe counting as merge conflicts. What do you think? > > Now I've to investigate why I have a 'no common ancestor case', because I > think > this should not have happened. > > Regards, > Lluís > ___ > 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
Re: [fossil-users] Warnings on no common ancestor
On Fri, Feb 10, 2012 at 10:47:21AM +0100, Ramon Ribó wrote: > > Additionally, "fossil merge -n | grep" will not find them, because they > > appear > > at stderr. > > What about?: > > fossil merge -n |& grep Well, of course. I know. But why the 'merge conflicts' don't go to stderr then, and only the warnings go to stderr? :) OTH, I found why the merge lost the common ancestor. A checkin in the branch we merge from says: F drivers/name2/CMakeLists.txt 7502f964180caca18854c362a143b03db759098b w drivers/name1/CMakeLists.txt F drivers/name2/DllMain.cpp e49061623fcbf8ab77bcf1116ac7b0c907ef9992 w drivers/name1/DllMain.cpp F drivers/name2/Name2FG.cpp a4be6efa0ecef9295a08b11eed5b432d0fb563f7 w drivers/name1/Name1FG.cpp F drivers/name2/Name2FG.hpp 9a911076e9a69570f07daab67a516e4d2e954eed w drivers/name1/Name1FG.hpp F drivers/name2/driver.cpp 0988a330147d0aaf0b61aca8b07bcc484abd83c8 w drivers/name1/driver.cpp There, most files were not only renamed, but also with some change in content. Only DllMain did not have any change in content, and it was the only one properly merged. The rest caused a "no common ancestor error". It looks to me that fossil gets confused in case of rename+changes in a single commit. Anyone knowing the code can confirm this? I think it should be fixed. Additionally, now we don't have an easy way to solve this, without causing future 'no common ancestor' problems. Isn't it? It's like we can't do the merge properly unless fossil gets fixed. If you have any trick we can use, let us know. Thank you, Lluís. > El 10 de febrer de 2012 10:30, Lluís Batlle i Rossell > ha escrit: > > Hello, > > > > I had troubles in a big merge of hundreds of files, where five filse had a > > message like this: > > fossil: WARNING - no common ancestor: ... > > > > I did not notice them along the list of files, because the final abstract of > > merge conflicts does not include them. > > > > Additionally, "fossil merge -n | grep" will not find them, because they > > appear > > at stderr. > > > > I'd prefer those 'no common ancestor' to appear somehow at the final > > abstract, > > maybe counting as merge conflicts. What do you think? > > > > Now I've to investigate why I have a 'no common ancestor case', because I > > think > > this should not have happened. > > > > Regards, > > Lluís > > ___ > > 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil artifact not complaining
Hello, "fossil artifact", if given a wrong artifact, does not complain at all. $ fossil artifact asdfasdfasdf File.hpp $ echo $? 0 This writes (or overwrites) a 0-bytes File.hpp silently. I think it should be fixed to a better behaviour (the command to emit an error and not overwrite the file). Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] stdout flush on external diff command
Hello, I'm using a diff-command "diff -u", and if I run: $ fossil diff all looks fine: a line with Index:, , and then the output of the diff command. But if I run: $ fossil diff | less First go the outputs of all the diff commands, and at the end, all the "Index:.." and === in a row. I think the diff_print_index() function that writes the "Index:" and the === needs a flush, to fix that. http://fossil-scm.org/index.html/artifact/313e3cafca96cd9f99ea58b90fed91a1d9322c0a?ln=30 Regards, Lluís. ___ 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] Warnings on no common ancestor
In my experience, if you try to do more than one rename or rename+changes to one file without a commit in the middle, this is going to give problems to fossil. There is some kind of bug there. In one of my examples, it even left the database unusable, and I had to do something very strange to make it work again. RR El 10 de febrer de 2012 10:54, Lluís Batlle i Rossell ha escrit: > On Fri, Feb 10, 2012 at 10:47:21AM +0100, Ramon Ribó wrote: >> > Additionally, "fossil merge -n | grep" will not find them, because they >> > appear >> > at stderr. >> >> What about?: >> >> fossil merge -n |& grep > > Well, of course. I know. But why the 'merge conflicts' don't go to stderr > then, > and only the warnings go to stderr? > :) > > OTH, I found why the merge lost the common ancestor. A checkin in the branch > we > merge from says: > F drivers/name2/CMakeLists.txt 7502f964180caca18854c362a143b03db759098b w > drivers/name1/CMakeLists.txt > F drivers/name2/DllMain.cpp e49061623fcbf8ab77bcf1116ac7b0c907ef9992 w > drivers/name1/DllMain.cpp > F drivers/name2/Name2FG.cpp a4be6efa0ecef9295a08b11eed5b432d0fb563f7 w > drivers/name1/Name1FG.cpp > F drivers/name2/Name2FG.hpp 9a911076e9a69570f07daab67a516e4d2e954eed w > drivers/name1/Name1FG.hpp > F drivers/name2/driver.cpp 0988a330147d0aaf0b61aca8b07bcc484abd83c8 w > drivers/name1/driver.cpp > > > There, most files were not only renamed, but also with some change in content. > Only DllMain did not have any change in content, and it was the only one > properly merged. The rest caused a "no common ancestor error". > > It looks to me that fossil gets confused in case of rename+changes in a single > commit. > > Anyone knowing the code can confirm this? I think it should be fixed. > Additionally, now we don't have an easy way to solve this, without causing > future 'no common ancestor' problems. Isn't it? > > It's like we can't do the merge properly unless fossil gets fixed. If you have > any trick we can use, let us know. > > Thank you, > Lluís. > > >> El 10 de febrer de 2012 10:30, Lluís Batlle i Rossell >> ha escrit: >> > Hello, >> > >> > I had troubles in a big merge of hundreds of files, where five filse had a >> > message like this: >> > fossil: WARNING - no common ancestor: ... >> > >> > I did not notice them along the list of files, because the final abstract >> > of >> > merge conflicts does not include them. >> > >> > Additionally, "fossil merge -n | grep" will not find them, because they >> > appear >> > at stderr. >> > >> > I'd prefer those 'no common ancestor' to appear somehow at the final >> > abstract, >> > maybe counting as merge conflicts. What do you think? >> > >> > Now I've to investigate why I have a 'no common ancestor case', because I >> > think >> > this should not have happened. >> > >> > Regards, >> > Lluís >> > ___ >> > 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 > ___ > 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
[fossil-users] Problems with renames (patch included)
Hello,
we found the source of error of our renames. It is not related to what I
mentioned on whether we changed the file + rename, or only renamed.
It's related to the lack of information in the manifests, when a checkin has
multiple parents, about where the rename comes from: the primary, or another
parent.
We wrote a patch that changes the find_filename_changes() function so it only
considers filename changes in case of "isPrim". This matches our way of using
fossil:
a) We never mix local renames with merge renames in a single checkin
b) We only merge between branches one forked of the other.
As the manifest lacks information about the source of the rename, I don't think
we can do much more with the current manifests.
Our troubles came when we had, ordered in time
trunk - rename done
mybranch - merge from trunk (takes the rename in)
trunk - some work
mybranch - merge from trunk again (It thinks there is a rename on P-V just
because the first 'merge from trunk' included it, while there is not any
rename on P-V). Failed merge.
So, as I said, the patch solves that situation for us. I hope someone can review
the patch.
Regards,
Lluís.
CHANGED src/path.c
--- src/path.c
+++ src/path.c
@@ -135,23 +135,23 @@
path.pEnd = path.pStart;
return path.pStart;
}
if( oneWayOnly ){
db_prepare(&s,
-"SELECT cid, 1 FROM plink WHERE pid=:pid "
+"SELECT cid, 1, isprim FROM plink WHERE pid=:pid "
);
}else if( directOnly ){
db_prepare(&s,
-"SELECT cid, 1 FROM plink WHERE pid=:pid AND isprim "
+"SELECT cid, 1, 1 FROM plink WHERE pid=:pid AND isprim "
"UNION ALL "
-"SELECT pid, 0 FROM plink WHERE cid=:pid AND isprim"
+"SELECT pid, 0, 1 FROM plink WHERE cid=:pid AND isprim"
);
}else{
db_prepare(&s,
-"SELECT cid, 1 FROM plink WHERE pid=:pid "
+"SELECT cid, 1, isprim FROM plink WHERE pid=:pid "
"UNION ALL "
-"SELECT pid, 0 FROM plink WHERE cid=:pid"
+"SELECT pid, 0, isprim FROM plink WHERE cid=:pid"
);
}
while( path.pCurrent ){
path.nStep++;
pPrev = path.pCurrent;
@@ -159,12 +159,20 @@
while( pPrev ){
db_bind_int(&s, ":pid", pPrev->rid);
while( db_step(&s)==SQLITE_ROW ){
int cid = db_column_int(&s, 0);
int isParent = db_column_int(&s, 1);
+int isPrim = db_column_int(&s, 2);
if( bag_find(&path.seen, cid) ) continue;
p = path_new_node(cid, pPrev, isParent);
+/* We store in p->isPrim if the relationship between parent and
+ * child is primary. That will be useful finding the renames.
+ *
+ * This is somehow a reuse of the isPrim member, that was thought
+ * for the path_common_ancestor() case. I don't know enough
+ * path_common_ancestor to see if it is any proper reuse. */
+p->isPrim = isPrim;
if( cid==iTo ){
db_finalize(&s);
path.pEnd = p;
path_reverse_path();
return path.pStart;
@@ -391,10 +399,27 @@
);
for(p=path.pStart; p; p=p->u.pTo){
int fnid, pfnid;
if( !p->fromIsParent && (p->u.pTo==0 || p->u.pTo->fromIsParent) ){
/* Skip nodes where the parent is not on the path */
+ continue;
+}
+if( !p->isPrim ){
+ /* When a checkin shows renames, but they are from multiple parents,
+ * we can't know from what parent the rename comes from.
+ *
+ * Has a simple 'merge' operation conveys the renames, we suppose that
+ * people don't mix local renames with renames coming from a merge in a
+ * single checkin.
+ * In this case, if isPrim is false, means that there was a merge
+ * involved. If there were renames, we suppose they come from the merge,
+ * and not from local changes (relative to the primary parent).
+ *
+ * I'm not sure if this works fine for merges between branches not
+ * directly related because the manifest does not convey enough
+ * information about the rename: from what parent the rename comes.
+ */
continue;
}
db_bind_int(&q1, ":mid", p->rid);
while( db_step(&q1)==SQLITE_ROW ){
fnid = db_column_int(&q1, 1);
___
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] fossil artifact not complaining
2012/2/10 Lluís Batlle i Rossell > I think it should be fixed to a better behaviour (the command to emit an > error > and not overwrite the file). > i've patched this locally to do: [stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe ./fossil: Could not resolve artifact name/ID. [stephan@hamsun:~/cvs/fossil/fossil]$ echo $? 1 If there are no objections i'll commit it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] stdout flush on external diff command
2012/2/10 Lluís Batlle i Rossell > First go the outputs of all the diff commands, and at the end, all the > "Index:.." and === in a row. I think the diff_print_index() function that > writes > the "Index:" and the === needs a flush, to fix that. > > http://fossil-scm.org/index.html/artifact/313e3cafca96cd9f99ea58b90fed91a1d9322c0a?ln=30 Wouldn't it be more correct to flush after returning from the external diff program? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] stdout flush on external diff command
2012/2/10 Lluís Batlle i Rossell : > Hello, > But if I run: > $ fossil diff | less > > First go the outputs of all the diff commands, and at the end, all the > "Index:.." and === in a row. I think the diff_print_index() function that > writes > the "Index:" and the === needs a flush, to fix that. This problem was fixed in the trunk on 2012-02-04 14:58:29 commit [dc96d73dd06ef] --Leo-- ___ 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] stdout flush on external diff command
On Fri, Feb 10, 2012 at 08:34:32AM -0500, Leo Razoumov wrote: > 2012/2/10 Lluís Batlle i Rossell : > > Hello, > > But if I run: > > $ fossil diff | less > > > > First go the outputs of all the diff commands, and at the end, all the > > "Index:.." and === in a row. I think the diff_print_index() function that > > writes > > the "Index:" and the === needs a flush, to fix that. > > This problem was fixed in the trunk on 2012-02-04 14:58:29 commit > [dc96d73dd06ef] Right! It does not happen using fossil trunk. Thank you. ___ 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] fossil artifact not complaining
hmm, on Fri, Feb 10, 2012 at 02:12:18PM +0100, Stephan Beal said that > 2012/2/10 Lluís Batlle i Rossell > > > I think it should be fixed to a better behaviour (the command to emit an > > error > > and not overwrite the file). > > > > i've patched this locally to do: > > [stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe > ./fossil: Could not resolve artifact name/ID. how about: $ ./fossil artifact abcdcafe ./fossil: abcdcafe: no such artifact -f -- courage is fear that has said its prayers. ___ 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] fossil artifact not complaining
On Fri, 10 Feb 2012 15:35:13 +0100 frantisek holop wrote: > > > I think it should be fixed to a better behaviour (the command to > > > emit an error > > > and not overwrite the file). > > > > > > > i've patched this locally to do: > > > > [stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe > > ./fossil: Could not resolve artifact name/ID. > > how about: > > $ ./fossil artifact abcdcafe > ./fossil: abcdcafe: no such artifact Sorry for another bikeshedding plug, but if we recall how perror() works, a more Unix-way approach to error reporting whould be reverse the static and varying parts, so that the error message becomes: no such artifact: abcdcafe ___ 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] fossil artifact not complaining
On Fri, Feb 10, 2012 at 3:35 PM, frantisek holop wrote:
> how about:
>
> $ ./fossil artifact abcdcafe
> ./fossil: abcdcafe: no such artifact
>
Because i'm pedantic ;). i prefer "could not resolve" because that is
actually what is happening: we are asking the fossil internals to convert
the user-provided symbol name into its internal form (an integer). We are
not asking fossil to search for a specific artifact, only to resolve its
symbolic name into another form.
It would be simple to provide the artifact name in the output, in which
case i would propose:
[stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe
./fossil: Could not resolve artifact [abcdcafe]
[stephan@hamsun:~/cvs/fossil/fossil]$ echo $?
1
i prefer that over:
... artifact: abcdcafe
because the colon implies that a more specific description follows, and
that's not what's happening here.
But of course those are just pedantic opinions. i don't feel strongly about
it one way or the other.
The current patch looks like:
[stephan@hamsun:~/cvs/fossil/fossil]$ f diff
Index: src/content.c
==
--- src/content.c
+++ src/content.c
@@ -322,10 +322,14 @@
const char *zFile;
db_find_and_open_repository(OPEN_ANY_SCHEMA, 0);
if( g.argc!=4 && g.argc!=3 ) usage("ARTIFACT-ID ?FILENAME? ?OPTIONS?");
zFile = g.argc==4 ? g.argv[3] : "-";
rid = name_to_rid(g.argv[2]);
+ if(0==rid){
+fossil_fatal("Could not resolve artifact [%s]",g.argv[2])
+ /*does not return*/;
+ }
content_get(rid, &content);
blob_write_to_file(&content, zFile);
}
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] fossil artifact not complaining
hmm, on Fri, Feb 10, 2012 at 07:00:54PM +0400, Konstantin Khomoutov said that > Sorry for another bikeshedding plug, but if we recall how perror() > works, a more Unix-way approach to error reporting whould be reverse > the static and varying parts, so that the error message becomes: > > no such artifact: abcdcafe yes, this is good as well of course :] -f -- after two weeks of dieting, all i lost was two weeks. ___ 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] fossil artifact not complaining
hmm, on Fri, Feb 10, 2012 at 04:08:03PM +0100, Stephan Beal said that > Because i'm pedantic ;). i prefer "could not resolve" because that is > actually what is happening: we are asking the fossil internals to convert > the user-provided symbol name into its internal form (an integer). We are > not asking fossil to search for a specific artifact, only to resolve its > symbolic name into another form. i think we are getting into a linguistic issue here, resolving is searching by its nature :] but i am fine with any verb.. > [stephan@hamsun:~/cvs/fossil/fossil]$ ./fossil artifact abcdcafe > ./fossil: Could not resolve artifact [abcdcafe] > [stephan@hamsun:~/cvs/fossil/fossil]$ echo $? > 1 you called the pedantic card, so i call and raise :] artifact takes as argument symbolic names as well and those are not inside brackets: fossil artifact tip fossil artifact tiptiptip but i see the commit is in already so this thread became academic :] -f -- name a psychological rock group? pink freud! ___ 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] fossil artifact not complaining
Guys, thanks for the debate, but the fix for this problem has already been checked in: http://www.fossil-scm.org/fossil/fdiff?v1=36f6acb63&v2=740078778803fa2b It prints "not found: NAME" or "ambiguous name: NAME" as appropriate. -- 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] Problems with renames (patch included)
2012/2/10 Lluís Batlle i Rossell > > So, as I said, the patch solves that situation for us. I hope someone can > review > the patch. > > A simpler change which accomplishes the same thing has been checked in at http://www.fossil-scm.org/fossil/ci/f0359882c9?sbs=1 Please let me know if this solves your problem or not. It seemed to work for me. -- 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] Problems with renames (patch included)
On Fri, Feb 10, 2012 at 10:32:00AM -0500, Richard Hipp wrote: > 2012/2/10 Lluís Batlle i Rossell > > > > > So, as I said, the patch solves that situation for us. I hope someone can > > review > > the patch. > > > > > A simpler change which accomplishes the same thing has been checked in at > > http://www.fossil-scm.org/fossil/ci/f0359882c9?sbs=1 > > Please let me know if this solves your problem or not. It seemed to work > for me. I thought of some change like this, and now I can't remember fully why I refused it... I imagine that I simply couldn't forecast side effects of the change. The change works for my case. As the merge renames tests still work, I can only agree with the change by now :) Thank you! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to maintain a set of patches?
I guess at some point with every SCM system one faces a challenge of a patch based workflow. I need to maintain a set of patches on a branch which are periodically reapplied as trunk moves forward. Git has "git rebase", Mercurial has "hg mq". What solution does fossil offer? --Leo-- ___ 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov wrote: > I guess at some point with every SCM system one faces a challenge of > a patch based workflow. I need to maintain a set of patches on a > branch which are periodically reapplied as trunk moves forward. If you apply a patch once, it is on that branch. To "reapply" a patch would be a no-op, since the changes are already present on the branch, unless for some reason you had backed the patch out since the prior application. Perhaps I don't understand what you are asking for? > Git > has "git rebase", Mercurial has "hg mq". What solution does fossil > offer? > > --Leo-- > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 15:28, Richard Hipp wrote: > On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov wrote: >> >> I guess at some point with every SCM system one faces a challenge of >> a patch based workflow. I need to maintain a set of patches on a >> branch which are periodically reapplied as trunk moves forward. > > If you apply a patch once, it is on that branch. To "reapply" a patch would > be a no-op, since the changes are already present on the branch, unless for > some reason you had backed the patch out since the prior application. > Perhaps I don't understand what you are asking for? > I am sorry if my language was not clear. Here are the diagrams: I start "my-patches" branch from trunk commit B and organize my changes as a set of patches each one addressing specific issue. AB-- <= trunk \-P1--P2--P3 <= my-patches Then after some time trunk moves forward ABCDE-- <= trunk \-P1--P2--P3 <= my-patches Now I want to reapply (I am avoiding word "rebase") my patches P1 through P3 to the trunk commit E to achieve something like this /-P1'--P2'--P3' <= my-patches ABCDE-- <= trunk \-P1--P2--P3 <= closed I am effectively rebasing my patches to the new trunk commit and I will close the leaf on the old branch. If I use merge then all three patches will be squashed into a single change-set. I would rather prefer to keep them as individual patches. --Leo-- ___ 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 3:46 PM, Leo Razoumov wrote: > On Fri, Feb 10, 2012 at 15:28, Richard Hipp wrote: > > On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov > wrote: > >> > >> I guess at some point with every SCM system one faces a challenge of > >> a patch based workflow. I need to maintain a set of patches on a > >> branch which are periodically reapplied as trunk moves forward. > > > > If you apply a patch once, it is on that branch. To "reapply" a patch > would > > be a no-op, since the changes are already present on the branch, unless > for > > some reason you had backed the patch out since the prior application. > > Perhaps I don't understand what you are asking for? > > > > I am sorry if my language was not clear. Here are the diagrams: > > I start "my-patches" branch from trunk commit B and organize my > changes as a set of patches > each one addressing specific issue. > > AB-- <= trunk > \-P1--P2--P3 <= my-patches > > Then after some time trunk moves forward > > ABCDE-- <= trunk > \-P1--P2--P3 <= my-patches > > Now I want to reapply (I am avoiding word "rebase") my patches P1 through > P3 > to the trunk commit E to achieve something like this > > /-P1'--P2'--P3' <= my-patches > ABCDE-- <= trunk > \-P1--P2--P3 <= closed > > I am effectively rebasing my patches to the new trunk commit and I > will close the leaf on the old branch. > > If I use merge then all three patches will be squashed into a single > change-set. I would rather prefer to keep them as individual patches. > fossil update D fossil merge --cherrypick P1 fossil commit --branch P1p fossil merge --cherrypick P2 fossil commit --tag P2p fossil merge --cherrypick P3 fossil commit --tag P3p > > --Leo-- > -- 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote: > > fossil update D > fossil merge --cherrypick P1 > fossil commit --branch P1p > fossil merge --cherrypick P2 > fossil commit --tag P2p > fossil merge --cherrypick P3 > fossil commit --tag P3p > Richard, thanks for the suggestion. Will I have to manually provide commit messages for each commit? --Leo-- ___ 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 4:07 PM, Leo Razoumov wrote: > On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote: > > > > fossil update D > > fossil merge --cherrypick P1 > > fossil commit --branch P1p > > fossil merge --cherrypick P2 > > fossil commit --tag P2p > > fossil merge --cherrypick P3 > > fossil commit --tag P3p > > > > Richard, > thanks for the suggestion. Will I have to manually provide commit > messages for each commit? > Yes. And you'll need to manually resolve any merge conflicts that come up to. > > --Leo-- > -- 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 16:15, Richard Hipp wrote: > > > On Fri, Feb 10, 2012 at 4:07 PM, Leo Razoumov wrote: >> >> On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote: >> > >> > fossil update D >> > fossil merge --cherrypick P1 >> > fossil commit --branch P1p >> > fossil merge --cherrypick P2 >> > fossil commit --tag P2p >> > fossil merge --cherrypick P3 >> > fossil commit --tag P3p >> > >> >> Richard, >> thanks for the suggestion. Will I have to manually provide commit >> messages for each commit? > > > Yes. And you'll need to manually resolve any merge conflicts that come up > to. I agree about merge conflicts. But as far as commit messages are concerned I hope that fossil could pre-populate the message with the text from the commit that is being cherry-picked. It would save lots of typing. --Leo-- ___ 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov wrote: > I hope that fossil could pre-populate the message with the > text from the commit that is being cherry-picked. It would save lots > of typing. > > A very reasonable suggestion. The latest trunk version of fossil does this. http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1 -- 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 maintain a set of patches?
On Fri, Feb 10, 2012 at 18:38, Richard Hipp wrote: > > > On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov wrote: >> >> I hope that fossil could pre-populate the message with the >> text from the commit that is being cherry-picked. It would save lots >> of typing. >> > > A very reasonable suggestion. The latest trunk version of fossil does > this. http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1 > Wow! That was fast (under 2 hours for a feature)!! Thanks, --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
