Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
To this point all my fossil usage is mostly-solo, whereas I've been using git on small teams. So when I said I miss it from git, I more properly meant it really comes in handy in my usage of git, and I know fossil doesn't have it, and if I were using fossil in the same contexts as I'm using git, what would I do without it?. I was thinking I would need stash if I were using fossil in a team, but I'm now pretty well convinced that I would need stash only if fossil weren't fossil. However, I've never yet used commit --private. I'm not sure whether it would meet my needs or not. My git workflow when pulling updates from my teammates often goes like this: $ git stash $ git pull # look around at what changed, make sure everything I'm interfacing with still works correctly $ git stash pop Granted that fossil will allow `fossil update` even if I don't commit first, still I think I would often want to use a workflow like the above. How does that look in fossil? My best guess is: $ fossil commit --private $ fossil update previous-branch-name # look around ... $ fossil merge private That's not quite as smooth as the git version, and it requires more attention--e.g., I actually updated to the wrong branch when I tried it out just now, forgetting that I was on 'experimental' instead of trunk in the repo I used before I tried it. And now my working copy and repo are in the desired state, except that foo.txt I added is ADDED_BY_MERGE instead of just ADDED, and I've got a private leaf still hanging around. I can live with those, but for once I think the git command is well named: I use it when I want to 'stash' some stuff away for a bit, then bring it back out again. I don't mean it to be a history event, much less one that appears picked out in gold on my timeline--I'm just shoving some stuff aside on my work table and taking it back out again. If I ignore that private branch and later do the same thing again, will everything still work well? Or should I close the existing private branch first (which requires bringing up the gui and at least 4 clicks)? In tentative conclusion, I think `git stash` really does offer something that isn't convenient to do in fossil, but I doubt it's the number one most important thing to add, and I could accept that it might be more complexity than is worthwhile. BTW, I just noticed that there's `fossil merge --backout`. That's not related to this, but it's cool. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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] Stash. Was: How should Fossil handle this merge conflict...
Hi, I'll say a few things since I was one of those who said git stash in a post :) git stash, I think, is not a necessity but a convenience. There is nothing that you can do with git stash that you can't do with branches. Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. One way to look at the git stash is as a private infinite undo tree. Despite the equivalence of actions of the scm systems, my mind thinks differently with git stash vs any step requiring undo. With stash, it is very obvious to me that absolutely nothing is lost, not even temporarily. If there were infinite undo in fossil, thoughts of disaster can be put to rest very easily. However, with only one level of undo, I don't feel comfortable about relying on undo to not lose work. Sometimes I type commands mechanically and so can't recall what exactly fossil undo will do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a I'd never used commit --private, so I just tried it. After the commit, the state of the checkout is the latest code. Whereas after a stash, the state of the checkout is that of the code *before* your changes. So a stash is a commit followed by a checkout of the earlier version. Again .. that stash combines the two steps in one command is a convenience, not a necessity. As for scenario (3), you're right. Fossil doesn't need stash to do this. Regards, -Kumar On Wed, Dec 15, 2010 at 9:09 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: It would be nice to have something like `git stash`, too. Probably the biggest thing I miss from git. I've been reading up on git-stash to see if Fossil needs a similar feature. So far I don't see the need, since stash doesn't do anything that Fossil doesn't already handle more or less automatically. Please enlighten me if I'm missing something obvious Several cases where the git-stash manpage and other resources recommend using git-stash are shown below, together with how you would do the same thing in Fossil (without a stash). Scenario (1): git-pull (the equivalent of fossil update in this context) will not pull in upstream changes due to merge conflicts. So you stash your local changes, then git-pull, then pop your stash. But Fossil has no problem pulling in upstream changes and simply marking the conflicts. And if you do a fossil update and you don't like all the conflicts you get, you can always fossil undo to go back to what you had, then commit your changes to a branch and work the conflicts out in a bunch of little merges, if that's what you'd prefer to do. Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. In Fossil, you can do this using fossil commit -private to create a private unpushable branch to store your incomplete change. I don't see how git-stash is any easier than fossil commit -private. In fact, it seems that commit -private is a little easier since it does not require learning a new mechanism (stash versus commit) but rather just a variation on an existing mechanism (commit) which presumably you already know very well. Scenario (3): You start out making changes but later decide that you want to put those changes on a branch, so you git-stash, then git-branch-new to create the new branch, then git-stash-pop, then git-commit. In Fossil, all that extra work is not necessary. You can commit to a branch at any time simply by adding the --branch argument to the fossil commit command line. And, you can even move a check-in that is already committed into a new or different branch using the check-in-edit feature of the fossil ui command. Fossil treats all check-ins as belonging to a single global DAG. Branches are designated using tags, which can be changed and rearranged after-the-fact. Git, on the other hand, appears to keep a separate DAG for each branch, meaning that checkins cannot be so easily move from one branch to another, necessitating tricks like the use of stash. So in summary - Fossil appears to already do everything that git-stash does and do it at least as
[fossil-users] Merge conflict notation
I have updated some of the merge conflict code to provide a little more detail.
Below is an example of this update in action.
0
1
2
3
BEGIN MERGE CONFLICT
89aba65d8683d417a305cc784afb82489617c665
initial checkin
444
8715f5bdc8de7d01fa9bc975d199ec5fe332c6da
new branch checkin
999
END MERGE CONFLICT
5
6
7
8
9
This change could hopefully provide some quick context on conflicts. Below is
the diff of the Fossil source that drives this new behavior. Any thoughts on
this idea?
Index: src/merge.c
===
--- src/merge.c
+++ src/merge.c
@@ -274,11 +274,11 @@
blob_read_from_file(v, zFullPath);
if( isBinary ){
rc = -1;
blob_zero(r);
}else{
- rc = blob_merge(p, m, v, r);
+ rc = blob_merge(p, m, v, r, vid, mid);
}
if( rc=0 ){
blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
Index: src/merge3.c
===
--- src/merge3.c
+++ src/merge3.c
@@ -144,20 +144,32 @@
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
** conflicts, the merge proceeds as best as it can and the number
** of conflicts is returns
*/
-int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut){
+int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut, int vid, int
mid){
int *aC1; /* Changes from pPivot to pV1 */
int *aC2; /* Changes from pPivot to pV2 */
int i1, i2;/* Index into aC1[] and aC2[] */
int nCpy, nDel, nIns; /* Number of lines to copy, delete, or insert */
int limit1, limit2;/* Sizes of aC1[] and aC2[] */
int nConflict = 0; /* Number of merge conflicts seen so far */
+
+ char *zLeft = (char*)malloc(512);
+ char *zRight = (char*)malloc(512);
+
static const char zBegin[] = BEGIN MERGE CONFLICT\n;
static const char zMid[] = \n;
static const char zEnd[] = END MERGE CONFLICT\n;
+
+ char *zLeftComment = db_text(0, SELECT comment FROM event where objid=%d,
vid);
+ char *zRightComment = db_text(0, SELECT comment FROM event where objid=%d,
mid);
+ char *zLeftUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d, vid);
+ char *zRightUuid= db_text(0, SELECT uuid FROM blob WHERE rid=%d, mid);
+
+ snprintf(zLeft, 512, %s\n %s\n, zLeftUuid, zLeftComment);
+ snprintf(zRight, 512, %s\n %s\n, zRightUuid, zRightComment);
blob_zero(pOut); /* Merge results stored in pOut */
/* Compute the edits that occur from pPivot = pV1 (into aC1)
** and pPivot = pV2 (into aC2). Each of the aC1 and aC2 arrays is
@@ -259,12 +271,14 @@
while( !ends_at_CPY(aC1[i1], sz) || !ends_at_CPY(aC2[i2], sz) ){
sz++;
}
DEBUG( printf(CONFLICT %d\n, sz); )
blob_appendf(pOut, zBegin);
+ blob_appendf(pOut, zLeft);
i1 = output_one_side(pOut, pV1, aC1, i1, sz);
blob_appendf(pOut, zMid);
+ blob_appendf(pOut, zRight);
i2 = output_one_side(pOut, pV2, aC2, i2, sz);
blob_appendf(pOut, zEnd);
blob_copy_lines(0, pPivot, sz);
}
@@ -290,10 +304,12 @@
blob_copy_lines(pOut, pV2, aC2[i2+2]);
}
free(aC1);
free(aC2);
+ free(zLeft);
+ free(zRight);
return nConflict;
}
/*
** COMMAND: test-3-way-merge
@@ -316,15 +332,15 @@
}
if( blob_read_from_file(v2, g.argv[4])0 ){
fprintf(stderr,cannot read %s\n, g.argv[4]);
fossil_exit(1);
}
- blob_merge(pivot, v1, v2, merged);
+ blob_merge(pivot, v1, v2, merged, 0, 0);
if( blob_write_to_file(merged, g.argv[5])blob_size(merged) ){
fprintf(stderr,cannot write %s\n, g.argv[4]);
fossil_exit(1);
}
blob_reset(pivot);
blob_reset(v1);
blob_reset(v2);
blob_reset(merged);
}
Index: src/update.c
===
--- src/update.c
+++ src/update.c
@@ -263,11 +263,11 @@
undo_save(zName);
content_get(ridt, t);
content_get(ridv, v);
blob_zero(e);
blob_read_from_file(e, zFullPath);
- rc = blob_merge(v, e, t, r);
+ rc = blob_merge(v, e, t, r, vid, tid);
if( rc=0 ){
if( !nochangeFlag ) blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
}
___
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 conflict notation
Why do not compact the 3 lines into one line?
RR
2010/12/15 Zach Todd zacht...@cis-partners.com:
I have updated some of the merge conflict code to provide a little more
detail. Below is an example of this update in action.
0
1
2
3
BEGIN MERGE CONFLICT
89aba65d8683d417a305cc784afb82489617c665
initial checkin
444
8715f5bdc8de7d01fa9bc975d199ec5fe332c6da
new branch checkin
999
END MERGE CONFLICT
5
6
7
8
9
This change could hopefully provide some quick context on conflicts. Below
is the diff of the Fossil source that drives this new behavior. Any thoughts
on this idea?
Index: src/merge.c
===
--- src/merge.c
+++ src/merge.c
@@ -274,11 +274,11 @@
blob_read_from_file(v, zFullPath);
if( isBinary ){
rc = -1;
blob_zero(r);
}else{
- rc = blob_merge(p, m, v, r);
+ rc = blob_merge(p, m, v, r, vid, mid);
}
if( rc=0 ){
blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
Index: src/merge3.c
===
--- src/merge3.c
+++ src/merge3.c
@@ -144,20 +144,32 @@
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
** conflicts, the merge proceeds as best as it can and the number
** of conflicts is returns
*/
-int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut){
+int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut, int vid, int
mid){
int *aC1; /* Changes from pPivot to pV1 */
int *aC2; /* Changes from pPivot to pV2 */
int i1, i2; /* Index into aC1[] and aC2[] */
int nCpy, nDel, nIns; /* Number of lines to copy, delete, or insert */
int limit1, limit2; /* Sizes of aC1[] and aC2[] */
int nConflict = 0; /* Number of merge conflicts seen so far */
+
+ char *zLeft = (char*)malloc(512);
+ char *zRight = (char*)malloc(512);
+
static const char zBegin[] = BEGIN MERGE CONFLICT\n;
static const char zMid[] = \n;
static const char zEnd[] = END MERGE CONFLICT\n;
+
+ char *zLeftComment = db_text(0, SELECT comment FROM event where
objid=%d, vid);
+ char *zRightComment = db_text(0, SELECT comment FROM event where
objid=%d, mid);
+ char *zLeftUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d,
vid);
+ char *zRightUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d,
mid);
+
+ snprintf(zLeft, 512, %s\n %s\n, zLeftUuid, zLeftComment);
+ snprintf(zRight, 512, %s\n %s\n, zRightUuid,
zRightComment);
blob_zero(pOut); /* Merge results stored in pOut */
/* Compute the edits that occur from pPivot = pV1 (into aC1)
** and pPivot = pV2 (into aC2). Each of the aC1 and aC2 arrays is
@@ -259,12 +271,14 @@
while( !ends_at_CPY(aC1[i1], sz) || !ends_at_CPY(aC2[i2], sz) ){
sz++;
}
DEBUG( printf(CONFLICT %d\n, sz); )
blob_appendf(pOut, zBegin);
+ blob_appendf(pOut, zLeft);
i1 = output_one_side(pOut, pV1, aC1, i1, sz);
blob_appendf(pOut, zMid);
+ blob_appendf(pOut, zRight);
i2 = output_one_side(pOut, pV2, aC2, i2, sz);
blob_appendf(pOut, zEnd);
blob_copy_lines(0, pPivot, sz);
}
@@ -290,10 +304,12 @@
blob_copy_lines(pOut, pV2, aC2[i2+2]);
}
free(aC1);
free(aC2);
+ free(zLeft);
+ free(zRight);
return nConflict;
}
/*
** COMMAND: test-3-way-merge
@@ -316,15 +332,15 @@
}
if( blob_read_from_file(v2, g.argv[4])0 ){
fprintf(stderr,cannot read %s\n, g.argv[4]);
fossil_exit(1);
}
- blob_merge(pivot, v1, v2, merged);
+ blob_merge(pivot, v1, v2, merged, 0, 0);
if( blob_write_to_file(merged, g.argv[5])blob_size(merged) ){
fprintf(stderr,cannot write %s\n, g.argv[4]);
fossil_exit(1);
}
blob_reset(pivot);
blob_reset(v1);
blob_reset(v2);
blob_reset(merged);
}
Index: src/update.c
===
--- src/update.c
+++ src/update.c
@@ -263,11 +263,11 @@
undo_save(zName);
content_get(ridt, t);
content_get(ridv, v);
blob_zero(e);
blob_read_from_file(e, zFullPath);
- rc = blob_merge(v, e, t, r);
+ rc = blob_merge(v, e, t, r, vid, tid);
if( rc=0 ){
if( !nochangeFlag ) blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
}
___
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
Re: [fossil-users] Merge conflict notation
Sometimes I wish the conflict notation was something like:
#error BEGIN MERGE CONFLICT
Instead of
BEGIN MERGE CONFLICT
But I know that would only work in C/C++/C#. I just wish there was some way
that the compiler could tell me about the merge conflict more clearly instead
of hunting for a syntax error side effect.
RW
Ron Wilson, Engineering Project Lead
(o) 434.455.6453, (m) 434.851.1612, www.harris.com
HARRIS CORPORATION | RF Communications Division assuredcommunicationsT
-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-
boun...@lists.fossil-scm.org] On Behalf Of Ramon Ribó
Sent: Wednesday, December 15, 2010 10:18 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Merge conflict notation
Why do not compact the 3 lines into one line?
RR
2010/12/15 Zach Todd zacht...@cis-partners.com:
I have updated some of the merge conflict code to provide a little more
detail. Below is an example of this update in action.
0
1
2
3
BEGIN MERGE CONFLICT
89aba65d8683d417a305cc784afb82489617c665
initial checkin
444
8715f5bdc8de7d01fa9bc975d199ec5fe332c6da
new branch checkin
999
END MERGE CONFLICT
5
6
7
8
9
This change could hopefully provide some quick context on conflicts.
Below is the diff of the Fossil source that drives this new behavior.
Any thoughts on this idea?
Index: src/merge.c
===
--- src/merge.c
+++ src/merge.c
@@ -274,11 +274,11 @@
blob_read_from_file(v, zFullPath);
if( isBinary ){
rc = -1;
blob_zero(r);
}else{
- rc = blob_merge(p, m, v, r);
+ rc = blob_merge(p, m, v, r, vid, mid);
}
if( rc=0 ){
blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
Index: src/merge3.c
===
--- src/merge3.c
+++ src/merge3.c
@@ -144,20 +144,32 @@
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
** conflicts, the merge proceeds as best as it can and the number
** of conflicts is returns
*/
-int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut){
+int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut, int vid,
int mid){
int *aC1; /* Changes from pPivot to pV1 */
int *aC2; /* Changes from pPivot to pV2 */
int i1, i2; /* Index into aC1[] and aC2[] */
int nCpy, nDel, nIns; /* Number of lines to copy, delete, or insert
*/
int limit1, limit2; /* Sizes of aC1[] and aC2[] */
int nConflict = 0; /* Number of merge conflicts seen so far */
+
+ char *zLeft = (char*)malloc(512);
+ char *zRight = (char*)malloc(512);
+
static const char zBegin[] = BEGIN MERGE CONFLICT\n;
static const char zMid[] = \n;
static const char zEnd[] = END MERGE CONFLICT\n;
+
+ char *zLeftComment = db_text(0, SELECT comment FROM event where
objid=%d, vid);
+ char *zRightComment = db_text(0, SELECT comment FROM event where
objid=%d, mid);
+ char *zLeftUuid = db_text(0, SELECT uuid FROM blob WHERE
rid=%d, vid);
+ char *zRightUuid = db_text(0, SELECT uuid FROM blob WHERE
rid=%d, mid);
+
+ snprintf(zLeft, 512, %s\n %s\n, zLeftUuid,
zLeftComment);
+ snprintf(zRight, 512, %s\n %s\n, zRightUuid,
zRightComment);
blob_zero(pOut); /* Merge results stored in pOut */
/* Compute the edits that occur from pPivot = pV1 (into aC1)
** and pPivot = pV2 (into aC2). Each of the aC1 and aC2 arrays is
@@ -259,12 +271,14 @@
while( !ends_at_CPY(aC1[i1], sz) || !ends_at_CPY(aC2[i2], sz) ){
sz++;
}
DEBUG( printf(CONFLICT %d\n, sz); )
blob_appendf(pOut, zBegin);
+ blob_appendf(pOut, zLeft);
i1 = output_one_side(pOut, pV1, aC1, i1, sz);
blob_appendf(pOut, zMid);
+ blob_appendf(pOut, zRight);
i2 = output_one_side(pOut, pV2, aC2, i2, sz);
blob_appendf(pOut, zEnd);
blob_copy_lines(0, pPivot, sz);
}
@@ -290,10 +304,12 @@
blob_copy_lines(pOut, pV2, aC2[i2+2]);
}
free(aC1);
free(aC2);
+ free(zLeft);
+ free(zRight);
return nConflict;
}
/*
** COMMAND: test-3-way-merge
@@ -316,15 +332,15 @@
}
if( blob_read_from_file(v2, g.argv[4])0 ){
fprintf(stderr,cannot read %s\n, g.argv[4]);
fossil_exit(1);
}
- blob_merge(pivot, v1, v2, merged);
+ blob_merge(pivot, v1, v2, merged, 0, 0);
if( blob_write_to_file(merged, g.argv[5])blob_size(merged) ){
fprintf(stderr,cannot write %s\n, g.argv[4]);
fossil_exit(1);
}
blob_reset(pivot);
blob_reset(v1);
Re: [fossil-users] Merge conflict notation
Might be a solution if a shortened uuid and the first part of the comment are
used.
From: fossil-users-boun...@lists.fossil-scm.org
[fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Ramon Ribó
[ram...@compassis.com]
Sent: Wednesday, December 15, 2010 10:17 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Merge conflict notation
Why do not compact the 3 lines into one line?
RR
2010/12/15 Zach Todd zacht...@cis-partners.com:
I have updated some of the merge conflict code to provide a little more
detail. Below is an example of this update in action.
0
1
2
3
BEGIN MERGE CONFLICT
89aba65d8683d417a305cc784afb82489617c665
initial checkin
444
8715f5bdc8de7d01fa9bc975d199ec5fe332c6da
new branch checkin
999
END MERGE CONFLICT
5
6
7
8
9
This change could hopefully provide some quick context on conflicts. Below
is the diff of the Fossil source that drives this new behavior. Any thoughts
on this idea?
Index: src/merge.c
===
--- src/merge.c
+++ src/merge.c
@@ -274,11 +274,11 @@
blob_read_from_file(v, zFullPath);
if( isBinary ){
rc = -1;
blob_zero(r);
}else{
- rc = blob_merge(p, m, v, r);
+ rc = blob_merge(p, m, v, r, vid, mid);
}
if( rc=0 ){
blob_write_to_file(r, zFullPath);
if( rc0 ){
printf(* %d merge conflicts in %s\n, rc, zName);
Index: src/merge3.c
===
--- src/merge3.c
+++ src/merge3.c
@@ -144,20 +144,32 @@
** The return is 0 upon complete success. If any input file is binary,
** -1 is returned and pOut is unmodified. If there are merge
** conflicts, the merge proceeds as best as it can and the number
** of conflicts is returns
*/
-int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut){
+int blob_merge(Blob *pPivot, Blob *pV1, Blob *pV2, Blob *pOut, int vid, int
mid){
int *aC1; /* Changes from pPivot to pV1 */
int *aC2; /* Changes from pPivot to pV2 */
int i1, i2;/* Index into aC1[] and aC2[] */
int nCpy, nDel, nIns; /* Number of lines to copy, delete, or insert */
int limit1, limit2;/* Sizes of aC1[] and aC2[] */
int nConflict = 0; /* Number of merge conflicts seen so far */
+
+ char *zLeft = (char*)malloc(512);
+ char *zRight = (char*)malloc(512);
+
static const char zBegin[] = BEGIN MERGE CONFLICT\n;
static const char zMid[] = \n;
static const char zEnd[] = END MERGE CONFLICT\n;
+
+ char *zLeftComment = db_text(0, SELECT comment FROM event where
objid=%d, vid);
+ char *zRightComment = db_text(0, SELECT comment FROM event where
objid=%d, mid);
+ char *zLeftUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d,
vid);
+ char *zRightUuid= db_text(0, SELECT uuid FROM blob WHERE rid=%d,
mid);
+
+ snprintf(zLeft, 512, %s\n %s\n, zLeftUuid, zLeftComment);
+ snprintf(zRight, 512, %s\n %s\n, zRightUuid,
zRightComment);
blob_zero(pOut); /* Merge results stored in pOut */
/* Compute the edits that occur from pPivot = pV1 (into aC1)
** and pPivot = pV2 (into aC2). Each of the aC1 and aC2 arrays is
@@ -259,12 +271,14 @@
while( !ends_at_CPY(aC1[i1], sz) || !ends_at_CPY(aC2[i2], sz) ){
sz++;
}
DEBUG( printf(CONFLICT %d\n, sz); )
blob_appendf(pOut, zBegin);
+ blob_appendf(pOut, zLeft);
i1 = output_one_side(pOut, pV1, aC1, i1, sz);
blob_appendf(pOut, zMid);
+ blob_appendf(pOut, zRight);
i2 = output_one_side(pOut, pV2, aC2, i2, sz);
blob_appendf(pOut, zEnd);
blob_copy_lines(0, pPivot, sz);
}
@@ -290,10 +304,12 @@
blob_copy_lines(pOut, pV2, aC2[i2+2]);
}
free(aC1);
free(aC2);
+ free(zLeft);
+ free(zRight);
return nConflict;
}
/*
** COMMAND: test-3-way-merge
@@ -316,15 +332,15 @@
}
if( blob_read_from_file(v2, g.argv[4])0 ){
fprintf(stderr,cannot read %s\n, g.argv[4]);
fossil_exit(1);
}
- blob_merge(pivot, v1, v2, merged);
+ blob_merge(pivot, v1, v2, merged, 0, 0);
if( blob_write_to_file(merged, g.argv[5])blob_size(merged) ){
fprintf(stderr,cannot write %s\n, g.argv[4]);
fossil_exit(1);
}
blob_reset(pivot);
blob_reset(v1);
blob_reset(v2);
blob_reset(merged);
}
Index: src/update.c
===
--- src/update.c
+++ src/update.c
@@ -263,11 +263,11 @@
undo_save(zName);
content_get(ridt, t);
content_get(ridv, v);
blob_zero(e);
blob_read_from_file(e, zFullPath);
- rc = blob_merge(v, e, t, r);
+ rc = blob_merge(v, e, t, r, vid, tid);
if( rc=0 ){
if( !nochangeFlag ) blob_write_to_file(r, zFullPath);
Re: [fossil-users] Merge conflict notation
On Dec 15, 2010, at 16:30 , Wilson, Ronald wrote: Sometimes I wish the conflict notation was something like: #error BEGIN MERGE CONFLICT Instead of BEGIN MERGE CONFLICT But I know that would only work in C/C++/C#. I just wish there was some way that the compiler could tell me about the merge conflict more clearly instead of hunting for a syntax error side effect. Doesn't this call for configurable notation? ;) Kind regards, Remigiusz Modrzejewski ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. An alternative idea would be think about it in terms of a patch queue. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Dec 15, 2010, at 16:53 , Joerg Sonnenberger wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.comwrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. An alternative idea would be think about it in terms of a patch queue. Actually what I do is (I install fossil as fl): 1) work freely on my big change, committing atomic changes fl commit --private fl commit --private [...] fl commit --private 2) prepare to make a real commit fl up trunk fl merge private 3) make sure everything works as expected, commit to the world fl commit This feels intuitive and does not leave space for disaster. Furthermore, at step 3 you can see an aggregated diff of the final shape of your big change. And yes, I think of it as a patch queue. How would a stash add value? Apart from the fact, that you have to clone to a new repo to get rid of old private commits. Kind regards, Remigiusz Modrzejewski ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 05:14:08PM +0100, Remigiusz Modrzejewski wrote: 1) work freely on my big change, committing atomic changes fl commit --private fl commit --private [...] fl commit --private 2) prepare to make a real commit fl up trunk fl merge private 3) make sure everything works as expected, commit to the world fl commit This feels intuitive and does not leave space for disaster. Furthermore, at step 3 you can see an aggregated diff of the final shape of your big change. And yes, I think of it as a patch queue. How would a stash add value? Apart from the fact, that you have to clone to a new repo to get rid of old private commits. Big change doesn't necessarily mean can be cut into smaller pieces. Especially in that case the incremental committing doesn't really work. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. An alternative idea would be think about it in terms of a patch queue. Joerg ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. Joerg ___ 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 conflict notation
I have updated the merge conflict code as well as config setup to allow for
configurable notation. The following now appears when calling fossil set.
auto-captcha
auto-shun
autosync (local) 1
binary-glob
clearsign
conflict-start (local) BEGIN MERGE CONFLICT
conflict-mid (local) ==
conflict-end (local) END MERGE CONFLICT
diff-command
dont-push
editor
gdiff-command
ignore-glob
http-port
localauth(local) 0
manifest
mtime-changes
pgp-command
proxy
repo-cksum
ssh-command
web-browser
As an example, this is the output on a merge conflict.
0
1
2
3
BEGIN MERGE CONFLICT 5d1cd2ac61 add testfile1
999
== 8eaf3091c7 change testfile1
444
END MERGE CONFLICT
5
6
7
8
9
Below is the diff on the Fossil source code. Any thoughts on this?
Index: src/db.c
===
--- src/db.c
+++ src/db.c
@@ -1025,10 +1025,14 @@
Blob hash;
Blob manifest;
db_set(content-schema, CONTENT_SCHEMA, 0);
db_set(aux-schema, AUX_SCHEMA, 0);
+ db_set(conflict-start, BEGIN MERGE CONFLICT, 0);
+ db_set(conflict-mid, ==, 0);
+ db_set(conflict-end, END MERGE CONFLICT\n, 0);
+
if( makeServerCodes ){
db_multi_exec(
INSERT INTO config(name,value)
VALUES('server-code', lower(hex(randomblob(20;
INSERT INTO config(name,value)
@@ -1541,29 +1545,32 @@
int width;/* Width of display. 0 for boolean values */
char const *def; /* Default value */
};
#endif /* INTERFACE */
struct stControlSettings const ctrlSettings[] = {
- { auto-captcha, autocaptcha,0, on },
- { auto-shun, 0,0, on },
- { autosync, 0,0, on },
- { binary-glob, 0, 32, },
- { clearsign, 0,0, off },
- { diff-command, 0, 16, },
- { dont-push, 0,0, off },
- { editor,0, 16, },
- { gdiff-command, 0, 16, gdiff },
- { ignore-glob, 0, 40, },
- { http-port, 0, 16, 8080},
- { localauth, 0,0, off },
- { manifest, 0,0, off },
- { mtime-changes, 0,0, on },
- { pgp-command, 0, 32, gpg --clearsign -o },
- { proxy, 0, 32, off },
- { repo-cksum,0,0, on },
- { ssh-command, 0, 32, },
- { web-browser, 0, 32, },
+ { auto-captcha, autocaptcha,0, on },
+ { auto-shun, 0,0, on },
+ { autosync, 0,0, on },
+ { binary-glob,0, 32, },
+ { clearsign, 0,0, off },
+ { conflict-start, 0, 32, BEGIN MERGE CONFLICT},
+ { conflict-mid, 0, 32, },
+ { conflict-end, 0, 32, END MERGE CONFLICT\\n },
+ { diff-command, 0, 16, },
+ { dont-push, 0,0, off },
+ { editor, 0, 16, },
+ { gdiff-command, 0, 16, gdiff },
+ { ignore-glob,0, 40, },
+ { http-port, 0, 16, 8080},
+ { localauth, 0,0, off },
+ { manifest, 0,0, off },
+ { mtime-changes, 0,0, on },
+ { pgp-command,0, 32, gpg --clearsign -o },
+ { proxy, 0, 32, off },
+ { repo-cksum, 0,0, on },
+ { ssh-command,0, 32, },
+ { web-browser,0, 32, },
{ 0,0,0,0 }
};
/*
** COMMAND: settings
@@ -1596,10 +1603,16 @@
** purposes. Example: *.xml
**
**clearsignWhen enabled, fossil will attempt to sign all commits
** with gpg. When disabled (the default), commits will
** be
Re: [fossil-users] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine jos...@letterblock.com wrote: Scenario (2): You are in the middle of a big change when a minor bug report comes in. You stash your incomplete change, fix the minor bug, then pop your stash to continue working on your big change. This is actually the main usage I can think of. Consider a minor variation of this. You have done your big change and want to update to the latest version and see that someone else has done a commit in the mean time. When do you merge? First variant is commit first and merge in the second step. This can be done already, but can make it non-intuitive what the commit did, especially if the merge ends up being non-trivial. The other approach is to merge first and commit afterwards. For that second approach, stash is useful. This last sentence is the part I don't get. How is stash any more useful here that committing to a branch (public or private) or fork and then merging in a separate step? To my mind, it is just yet-another-command to have to learn. Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. I prefer the current fossil undo option (with later commit to a branch), and I don't like much those automatic merges done directly, unless they are optional. The fossil undo + new branch, for those who believe in saving as much as possible in the history of the file tree, even encourages the public resolution of the merge. For those not wanting to save that publicly, those can even use -private. I don't think we need 'stash'; at most, I think we would get advantage of: - a precise description of what fossil undo is going to do in any case. Maybe it is only my trouble, but I'm not sure what will happen if I run undo after I changed things after fossil merge, for example. - and a reliable way of detecting if the merge is trivial or not, to be able to to undo + branch as soon as possible in case of non triviality. The recent improvement on notifying conflicts goes in that direction, I think. 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 10:50:52PM +0100, Lluís Batlle i Rossell wrote: On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: Having incomplete changes in the tree is bad for things like bisect. It shouldn't be forced. The big issue here is that merging changes the working copy. If you can make it possible that automatic merges can be done directly, without changing the working copy, that would be good enough for this purpose. I prefer the current fossil undo option (with later commit to a branch), and I don't like much those automatic merges done directly, unless they are optional. The trouble with fossil undo is that it throws away the state at some point, e.g. it very volatile and I wouldn't trust it with my data. Automatic merge + commit should definitely be optional behavior. It might make sense to use it as default and fall back to manual merging otherwise. The fossil undo + new branch, for those who believe in saving as much as possible in the history of the file tree, even encourages the public resolution of the merge. For those not wanting to save that publicly, those can even use -private. I would prefer to know in advance whether I can merge without problems or not. Problems against the base revision, not the working copy. This is important to decide whether I have to get a new working copy to do the merge, especially when working on a private branch. I don't think we need 'stash'; at most, I think we would get advantage of: - a precise description of what fossil undo is going to do in any case. Maybe it is only my trouble, but I'm not sure what will happen if I run undo after I changed things after fossil merge, for example. Ack. - and a reliable way of detecting if the merge is trivial or not, to be able to to undo + branch as soon as possible in case of non triviality. The recent improvement on notifying conflicts goes in that direction, I think. Ack. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] basic questions about fossil
Hi Richard, I discovered fossil yesterday while reading the Wikipedia page that compares version control systems. I read lots of the material on the fossil website, and I must say that fossil looks very promising. Congratulations on what appears to a great piece of software! I have very little experience with version control, but I'd like to start using it more. I work in a Clearcase environment, but I don't use Clearcase myself because I work relatively independently (I am an aerospace research engineer who writes prototype software for research in air traffic control). I recently started doing a little research on the alternatives. I watched Linus Torvalds talk at Google, and he sold me on distributed version control. At first I was interested in Git and BitKeeper. Then I discovered Bazaar, and I was almost ready to start using it, but I decided to take one more look at the options. When I saw fossil, I figured, with a name like that, it's a real long shot, but I'll take a look anyway. Sure enough, it looks impressive. I just have a few questions. The Bazaar website claims that one advantage of Bazaar over Git is that it properly handles renames of files and directories. That is important to me. I'm very particular about filenames and directory structure, and I don't want to feel that I am stuck with the first file name or directory structure I chose because changing it will confuse my version control system (or confuse the people using it). How does fossil compare to Bazaar in that regard? While your at it, I'd be interested to know how it compares to Bazaar in general. I downloaded fossil and gave it a try on my Linux machine. The first time I tried to add files, I got stuck in some mode that I could not get out of. Apparently, my EDITOR environment variable was not set, and I was supposed to give a comment. Fossil was showing a question mark, but I did not know what it wanted, and not even Control-C would get me out. I ended up killing the terminal and deleting the repository I had just created in case it was corrupted. How was I supposed to respond to the question mark? By the way, why do these version control systems insist on a comment? Yes, I understand that commenting is good practice, but does that mean it should be mandatory and the version control system should force me to write one? I tend to think not. Regards, Russ Paielli -- http://RussP.us ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
