Re: [fossil-users] In-line versus side-by-side diffs
On Mon, Feb 6, 2012 at 23:26, Richard Hipp d...@sqlite.org wrote: A lot of people have been telling me that they prefer the unified or context style in-line diffs over side-by-side diffs. And I have to admit that sometimes an in-line diff is easier to read and understand. But side-by-side diffs, especially with the recent enhancements, sometime give a much clearer picture of what changed. I find both types of diffs complementary to each other and I am happy that fossil provides both. Traditional unified diffs are useful to generate and review patches while side-by-side diffs provide a great bird's eye view of the the battle field. Fossil is unique that it generates all these different views out of the box from the same executable while the competition would require installing/configuring 3-rd party stand-alone applications to achieve the same results. --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] In-line versus side-by-side diffs
On Mon, Feb 06, 2012 at 11:26:16PM -0500, Richard Hipp wrote: A lot of people have been telling me that they prefer the unified or context style in-line diffs over side-by-side diffs. And I have to admit that sometimes an in-line diff is easier to read and understand. But side-by-side diffs, especially with the recent enhancements, sometime give a much clearer picture of what changed. The following is a dramatic example of this that I stumbled over while testing. First the in-line diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=0#chunk3 Can you tell what changed? Now look at the side-by-side diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=1#chunk3 Surely you will admit that, in this case at least, the side-by-side diff gives a much clearer picture of what happened -- D. Richard Hipp d...@sqlite.org For sure, unified diff is very poor in that particular exemple. Unified or context diff will work well when single lines (or small block of lines) with change in them, where you have the 2 lines one next to the other. But with the improvement done on the sbsdiff version, I start to like sbsdiff a lot more. One case where I will switch to unified mode is when comparing long lines, since sbsdiff trunk them. A usefull option for sbsdiff would be to have an option to ignore white spaces (vertical and horizontal). Sometimes, this help for files with very messy changes done by a too smart editor or if someone do some changes in the same commit he convert tabs to spaces. Good Job.. -- Martin G. ___ 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] In-line versus side-by-side diffs
On Mon, Feb 06, 2012 at 10:54:50PM -0600, Bill Burdick wrote: I think something like this would help the traditional diff format a lot: http://www.redmine.org/issues/7139 Bill Latest changes doesn't something like that? -- Martin G. ___ 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] In-line versus side-by-side diffs
On Tue, Feb 07, 2012 at 06:11:42AM -0500, Martin Gagnon wrote: On Mon, Feb 06, 2012 at 10:54:50PM -0600, Bill Burdick wrote: I think something like this would help the traditional diff format a lot: http://www.redmine.org/issues/7139 Bill Latest changes doesn't something like that? I think he means the horizontal in-line diff. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] PATCH: fossil diff --brief outputs only whether files differ
Hi Richard,
please, find attached a patch that introduces --brief (short -q)
option to fossil diff that acts analogous to regular diff --brief
or diff -q. It suppresses diff contents and outputs just the file
names that differ. Output format is similar to fossil changes.
But unlike fossil changes fossil diff -q can take --from and --to
options and, thus, compare arbitrary commits.
Affects of -q/--brief are limited to the internal diff implementation
and is noop if external diff is used.
The patch is against the trunk [b1530c29ab].
Thanks,
--Leo--
Fossil-SCM patch against trunk commit:
artifact: b1530c29ab659a56f488e4386f242eb758858f22
tags: trunk
type: Check-in by drh on 2012-02-07 04:15:41
comment: Add chunk number fragment marks to HTML diff output.
Index: src/diffcmd.c
==
--- src/diffcmd.c~0 2012-02-07 07:49:53.0 -0500
+++ src/diffcmd.c 2012-02-07 07:32:34.0 -0500
@@ -19,15 +19,27 @@
*/
#include config.h
#include diffcmd.h
#include assert.h
+/* Flag to supress diff output if -q or --brief option is given
+ * to the internal diff command
+ */
+static int hasQFlag = 0;
+
/*
** Print the Index: message that patches wants to see at the top of a diff.
+** If -q/--brief then print CHANGED instead.
*/
void diff_print_index(const char *zFile, int diffFlags){
- if( (diffFlags DIFF_SIDEBYSIDE)==0 ){
+if( (diffFlags DIFF_SIDEBYSIDE) ){
+ return;
+} else if( hasQFlag ){
+ char *z = mprintf(CHANGED %s\n, zFile);
+ fossil_print(%s, z);
+ fossil_free(z);
+ } else {
char *z = mprintf(Index: %s\n%.66c\n, zFile, '=');
fossil_print(%s, z);
fossil_free(z);
}
}
@@ -35,10 +47,12 @@ void diff_print_index(const char *zFile,
/*
** Print the +++/--- filename lines for a diff operation.
*/
void diff_print_filenames(const char *zLeft, const char *zRight, int diffFlags){
char *z = 0;
+ if( hasQFlag ){ return; } /* don't print anything in -q/--brief mode */
+
if( diffFlags DIFF_SIDEBYSIDE ){
int w = diff_width(diffFlags);
int n1 = strlen(zLeft);
int x;
if( n1w*2 ) n1 = w*2;
@@ -89,11 +103,11 @@ void diff_file(
/* Compute and output the differences */
blob_zero(out);
text_diff(pFile1, file2, out, diffFlags);
if( blob_size(out) ){
diff_print_filenames(zName, zName2, diffFlags);
- fossil_print(%s\n, blob_str(out));
+ if( !hasQFlag ){ fossil_print(%s\n, blob_str(out)); }
}
/* Release memory resources */
blob_reset(file2);
blob_reset(out);
@@ -148,11 +162,11 @@ void diff_file_mem(
Blob out; /* Diff output text */
blob_zero(out);
text_diff(pFile1, pFile2, out, diffFlags);
diff_print_filenames(zName, zName, diffFlags);
-fossil_print(%s\n, blob_str(out));
+if( !hasQFlag ){ fossil_print(%s\n, blob_str(out)); }
/* Release memory resources */
blob_reset(out);
}else{
Blob cmd;
@@ -199,10 +213,11 @@ static void diff_one_against_disk(
historical_version_of_file(zFrom, blob_str(fname), content, isLink, 0, 0);
if( !isLink != !file_wd_islink(zFrom) ){
fossil_print(cannot compute difference between
symlink and regular file\n);
}else{
+diff_print_index(zFileTreeName, diffFlags);
diff_file(content, zFileTreeName, zFileTreeName, zDiffCmd, diffFlags);
}
blob_reset(content);
blob_reset(fname);
}
@@ -283,11 +298,11 @@ static void diff_all_against_disk(
}else if( isNew ){
fossil_print(ADDED%s\n, zPathname);
srcid = 0;
if( !asNewFile ){ showDiff = 0; }
}else if( isChnged==3 ){
- fossil_print(ADDED_BY_MERGE %s\n, zPathname);
+ fossil_print(ADDED_BY_MERGE %s\n, zPathname);
srcid = 0;
if( !asNewFile ){ showDiff = 0; }
}
if( showDiff ){
Blob content;
@@ -403,27 +418,27 @@ static void diff_all_two_versions(
cmp = -1;
}else{
cmp = fossil_strcmp(pFromFile-zName, pToFile-zName);
}
if( cmp0 ){
- fossil_print(DELETED %s\n, pFromFile-zName);
+ fossil_print(DELETED %s\n, pFromFile-zName);
if( asNewFlag ){
diff_manifest_entry(pFromFile, 0, zDiffCmd, diffFlags);
}
pFromFile = manifest_file_next(pFrom,0);
}else if( cmp0 ){
- fossil_print(ADDED %s\n, pToFile-zName);
+ fossil_print(ADDED%s\n, pToFile-zName);
if( asNewFlag ){
diff_manifest_entry(0, pToFile, zDiffCmd, diffFlags);
}
pToFile = manifest_file_next(pTo,0);
}else if( fossil_strcmp(pFromFile-zUuid, pToFile-zUuid)==0 ){
/* No changes */
pFromFile = manifest_file_next(pFrom,0);
pToFile = manifest_file_next(pTo,0);
}else{
- /* fossil_print(CHANGED %s\n, pFromFile-zName); */
+ /* fossil_print(CHANGED %s\n, pFromFile-zName); */
diff_manifest_entry(pFromFile, pToFile, zDiffCmd, diffFlags);
pFromFile =
Re: [fossil-users] In-line versus side-by-side diffs
Sorry -- I didn't explain that. Look at the second highlighted section: foo = User is shown in light colors both red and green because those parts of the lines are the same in each version but the parts of the lines that are different are shown in darker colors. Bill 2012/2/7 Lluís Batlle i Rossell vi...@viric.name On Tue, Feb 07, 2012 at 06:11:42AM -0500, Martin Gagnon wrote: On Mon, Feb 06, 2012 at 10:54:50PM -0600, Bill Burdick wrote: I think something like this would help the traditional diff format a lot: http://www.redmine.org/issues/7139 Bill Latest changes doesn't something like that? I think he means the horizontal in-line diff. ___ 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] zip/tar patch
hi there,
the motivation for this patch was that the zip and tarball links
from the web ui get a filename and checkout for free, while they
are a mandatory parameters for the command line.
so i tried to unify it a bit: the default archive name is now both
from web and cli the same, a lowercased project name followed by the
artifact ID. spaces are substituted with '-'.
$ fossil zip
fossil-030035345c.zip: 2944427 bytes
$ fossil zip tip
fossil-030035345c.zip: 2944427 bytes
$ fossil zip -o f.zip
f.zip: 2944427 bytes
$ fossil zip -o f.zip tip
f.zip: 2944427 bytes
$ fossil tar
fossil-030035345c.tgz: 2944427 bytes
$ fossil tar tip
fossil-030035345c.tgz: 2944427 bytes
$ fossil tar -o f.tgz
f.zip: 2944427 bytes
$ fossil tar -o f.tgz tip
f.zip: 2944427 bytes
$ fossil help zip
Usage: fossil zip [--name DIRECTORY] [-o OUTPUTFILE]
[-R REPOSITORY] [VERSION]
Generate a ZIP archive containing VERSION of the checkout.
If VERSION is omitted, the current checkout is used.
The name of the resulting archive can be set using the -o option,
otherwise it will be derived from the project name followed by the
check-in's artifact ID. Unless the --name option is specified, the
the top-level directory inside the archive will have the same name.
Options:
--name DIRECTORY Name of the top-level directory inside
the archive.
-o OUTPUTFILE Name of the archive.
-R|--repository FILE Use the repository in FILE.
See also: tarball
--- src/info.c
+++ src/info.c
@@ -500,11 +500,18 @@
@ td%h(zUser) @ %h(zIpAddr) on %s(zDate)/td/tr
}
db_finalize(q);
}
if( g.perm.History ){
- const char *zProjName = db_get(project-name, unnamed);
+ char *zProjName = db_get(project-name, unnamed);
+ int i;
+ for(i=0; istrlen(zProjName); i++){
+zProjName[i] = fossil_tolower(zProjName[i]);
+if( zProjName[i]==' ' ){
+ zProjName[i] = '-';
+ }
+ }
@ trthTimelines:/thtd
@ a href=%s(g.zTop)/timeline?f=%S(zUuid)family/a
if( zParent ){
@ | a href=%s(g.zTop)/timeline?p=%S(zUuid)ancestors/a
}
@@ -526,16 +533,14 @@
@ /td/tr
@ trthOthernbsp;Links:/th
@ td
@ a href=%s(g.zTop)/dir?ci=%S(zUuid)files/a
if( g.perm.Zip ){
-char *zUrl = mprintf(%s/tarball/%s-%S.tar.gz?uuid=%s,
- g.zTop, zProjName, zUuid, zUuid);
-@ | a href=%s(zUrl)Tarball/a
+@ | a href=%s(g.zTop)/tarball/%s(zProjName)-%S(zUuid).tgz=%s(zUuid)
+@ Tarball/a
@ | a
href=%s(g.zTop)/zip/%s(zProjName)-%S(zUuid).zip?uuid=%s(zUuid)
@ ZIP archive/a
-fossil_free(zUrl);
}
@ | a href=%s(g.zTop)/artifact/%S(zUuid)manifest/a
if( g.perm.Write ){
@ | a href=%s(g.zTop)/ci_edit?r=%S(zUuid)edit/a
}
--- src/tar.c
+++ src/tar.c
@@ -525,42 +525,63 @@
}
/*
** COMMAND: tarball*
**
-** Usage: %fossil tarball VERSION OUTPUTFILE [--name DIRECTORYNAME]
[-R|--repository REPO]
+** Usage: %fossil tarball [--name DIRECTORY] [-o OUTPUTFILE]
+** [-R REPOSITORY] VERSION
+**
+** Generate a compressed tarball archive containing VERSION of the
+** project. If VERSION is omitted, the current checkout is used.
+**
+** The name of the resulting archive can be set using the -o option,
+** otherwise it will be derived from the project name followed by the
+** check-in's artifact ID. Unless the --name option is specified, the
+** the top-level directory inside the archive will have the same name.
+**
+** Options:
+** --name DIRECTORY Name of the top-level directory inside
+** the archive.
+** -o OUTPUTFILE Name of the archive.
+** -R|--repository FILE Use the repository in FILE.
**
-** Generate a compressed tarball for a specified version. If the --name
-** option is used, its argument becomes the name of the top-level directory
-** in the resulting tarball. If --name is omitted, the top-level directory
-** named is derived from the project name, the check-in date and time, and
-** the artifact ID of the check-in.
+** See also: zip
*/
void tarball_cmd(void){
int rid;
Blob tarball;
const char *zName;
+ const char *fName;
+ int wrote;
zName = find_option(name, 0, 1);
+ fName = find_option(o, o, 1);
db_find_and_open_repository(0, 0);
- if( g.argc!=4 ){
-usage(VERSION OUTPUTFILE);
+ if( g.argc!=2 g.argc!=3 ){
+usage([--name DIRECTORY] [-o OUTPUTFILE] [-R REPOSITORY] [VERSION]);
}
- rid = name_to_typed_rid(g.argv[2], ci);
+ if( g.argc==3 ){
+rid = name_to_typed_rid(g.argv[2], ci);
+ }else{
+rid = db_lget_int(checkout,0);
+ }
if( zName==0 ){
-zName = db_text(default-name,
- SELECT replace(%Q,' ','_')
- || strftime('_%%Y-%%m-%%d_%%H%%M%%S_', event.mtime)
+zName = db_text(unnamed,
+ SELECT lower(replace(%Q,' ','-'))
+
Re: [fossil-users] zip/tar patch
On Tue, Feb 7, 2012 at 7:48 PM, frantisek holop min...@obiit.org wrote: so i tried to unify it a bit: the default archive name is now both from web and cli the same, a lowercased project name followed by the artifact ID. spaces are substituted with '-'. Hi! Out of curiosity: why force lower-case? That seems like an arbitrary decision without a technical reason. i have one Java tree in Fossil for which i highly prefer a CamelCasedName. :-? -- - 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] zip/tar patch
hmm, on Tue, Feb 07, 2012 at 08:59:37PM +0100, Stephan Beal said that On Tue, Feb 7, 2012 at 7:48 PM, frantisek holop min...@obiit.org wrote: so i tried to unify it a bit: the default archive name is now both from web and cli the same, a lowercased project name followed by the artifact ID. spaces are substituted with '-'. Out of curiosity: why force lower-case? That seems like an arbitrary decision without a technical reason. i have one Java tree in Fossil for which i highly prefer a CamelCasedName. no reason really, matter of personal preference. i was sure that this part wouldnt be left without discussion :] it is trivial to remove from the patch of course. -f -- dogmatism: puppyism come to its full growth. ___ 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] zip/tar patch
On Tue, Feb 7, 2012 at 9:44 PM, frantisek holop min...@obiit.org wrote: hmm, on Tue, Feb 07, 2012 at 08:59:37PM +0100, Stephan Beal said that Out of curiosity: why force lower-case? That seems like an arbitrary decision without a technical reason. i have one Java tree in Fossil for which i highly prefer a CamelCasedName. no reason really, matter of personal preference. i was sure that this part wouldnt be left without discussion :] i thought maybe you did it just to get a reaction ;). In any case, i like the feature, i just don't like the forced lower-casing. (To be clear: not that my vote counts for anything!) -- - 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] zip/tar patch
hmm, on Tue, Feb 07, 2012 at 09:48:23PM +0100, Stephan Beal said that In any case, i like the feature, i just don't like the forced lower-casing. (To be clear: not that my vote counts for anything!) well it all comes down to if project name is a good data source for a filename.. anyway, i feel much stronger about spaces in filenames, that is mostly asking for trouble. -f -- to my embarrassment, i was born in bed with a lady! ___ 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] zip/tar patch
Agreed completely - spaces in filenames are evil. (let the flame wars begin ;) - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Feb 7, 2012 10:21 PM, frantisek holop min...@obiit.org wrote: hmm, on Tue, Feb 07, 2012 at 09:48:23PM +0100, Stephan Beal said that In any case, i like the feature, i just don't like the forced lower-casing. (To be clear: not that my vote counts for anything!) well it all comes down to if project name is a good data source for a filename.. anyway, i feel much stronger about spaces in filenames, that is mostly asking for trouble. -f -- to my embarrassment, i was born in bed with a lady! ___ 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_ file grows large
Hi List, I wonder why _FOSSIL_ file grows so fast. I did some little work with a clone of fossil source code repository (23MB) and over space of two days _FOSSIL_ reached 10MB. What gives? --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] _FOSSIL_ file grows large
On Tue, Feb 7, 2012 at 7:24 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I wonder why _FOSSIL_ file grows so fast. I did some little work with a clone of fossil source code repository (23MB) and over space of two days _FOSSIL_ reached 10MB. What gives? The _FOSSIL_ file contains (among other things) your stash and your undo history. What does sqlite3_analyzer _FOSSIL_ show you? Which tables are using the most space. Maybe it just needs to be vacuumed? --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
