Re: [fossil-users] Last call for "testerCleanup" branch review...

[tonyp]

Can someone shed some light (or point me to a link) as to what this new 
feature is supposed to do?  (I must have missed any prior discussion on 
this.)


-Original Message- 
From: Joe Mistachkin

Sent: Saturday, March 05, 2016 9:27 PM
To: fossil-...@mailinglists.sqlite.org
Cc: 'Fossil SCM user's discussion'
Subject: [fossil-users] Last call for "testerCleanup" branch review...


I think this branch is ready and I'm planning on merging these changes to
trunk on Tuesday, March 8th, 2016.  Please feel free to raise objections.

--
Joe Mistachkin

___
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] Shorter alias for FOSSIL AMEND --EDIT-COMMENT request

[tonyp]

Seems OK to me.

-Original Message- 
From: Ross Berteig

Sent: Friday, February 26, 2016 4:57 AM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Shorter alias for FOSSIL AMEND --EDIT-COMMENT 
request


On 2/25/2016 4:58 PM, to...@acm.org wrote:

Would it be possible to add a short version for the –-EDIT-COMMENT
option of the AMEND command (just like there is for –-comment)?
Something like –e perhaps?


A quick check of the handy /test-all-help page for references to -e
shows that no command uses it now, so it doesn't have any overloaded
meanings to confuse things. The checkin command has no option at all to
cause the comment to be edited (that is what happens if -m or -M are not
used). If it did, I suppose that --edit-comment would be its likely
name, and -e its likely short name.

So it looks like that was a six character edit to the amend command. Try
checkin [769bc7b4] as see if it does what you expected.

--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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] Shorter alias for FOSSIL AMEND --EDIT-COMMENT request

[tonyp]

Would it be possible to add a short version for the –-EDIT-COMMENT option of 
the AMEND command (just like there is for –-comment)?

Something like –e perhaps?

--EDIT-COMMENT is the one option I use most often when using the AMEND command 
to fix check-in comment typos, and this option is a bit too long to type all 
the time.

Thanks.___
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] Two questions

[tonyp]

1. How do you merge only certain files?


The way I deal with the problem you described is with the UPDATE command.

FOSSIL UPDATE BRANCH FILENAME

will merge only that specific file.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion for MERGE default comment

[tonyp]

When merging one branch to another, the merge usually reflects more than a 
single commit.

So, just like when a commit is aborted, the next time you try to commit you’re 
given the previously typed comment as default, it would be nice if after 
merging, the default comment for the next COMMIT (i.e., when not using the –m 
command-line option but the editor) was the accumulated comments of all 
check-ins represented in the merge.  One can then edit out what’s not 
important.  This is less work than trying to (remember and) type all details 
about the changes merged in.  (This is also useful when the merged in content 
comes from a private branch which may later be deleted losing all detailed 
comments about the changes.)

Thanks.___
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] Suggestion for MERGE default comment

[tonyp]

From: Stephan Beal 
Sent: Sunday, January 17, 2016 3:11 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Suggestion for MERGE default comment

On Sun, Jan 17, 2016 at 1:53 AM,  wrote:

  important.  This is less work than trying to (remember and) type all details 
about the changes merged in.  (This is also useful when the merged in content 
comes from a private branch which may later be deleted losing all detailed 
comments about the changes.)

i would argue that most people write 'merged in [other-branch]' and let those 
interested go read the commits for that branch.

Which is exactly why I mentioned the possibility of deleted private branches, 
losing the detailed commit comments from those branches!
Anyway, it was just an idea that would certainly save me some typing as I do 
this kind of commenting a lot.
But, I’ll submit to the (assumed) ‘most people’ argument. :)

Thanks.

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do." -- Bigby Wolf



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

[fossil-users] Display of *private* branches

[tonyp]

Would it possible to have private branches display as such (e.g., marked as 
PRIVATE) both in the UI ‘Branches’ screen, and the FOSSIL BRA cli command?

Thanks and Happy New Year!___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] PUSH --PRIVATE failure (bug?)

[tonyp]

Just reporting some probable bug.

I created a private branch during commit (in one step) and then tried to push 
it (with F PUSH –PRIVATE) on the remote repo (which is a file on a USB stick), 
and got this error, and the push failed (I tried several times).  The –db-check 
says OK on the database.

Push to file:// ... 
Round-trips: 2   Artifacts sent: 2  received: 0
Error: Database error: UNIQUE constraint failed: private.rid: {INSERT INTO 
private VALUES(21511)}
Round-trips: 2   Artifacts sent: 2  received: 0
Push done, sent: 225293  received: 771  ip:

I cannot send the repo file but if there are any test commands you want me to 
run that may help debug this issue, I’m all ears.

Thanks.___
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 mentioned on HN

[tonyp]

Hmm.. If one can create a private branch, do all draft work there and when done 
merge to trunk (or other non-private branch), then sync with the main repo, the 
main repo will not contain any traces of the private branch (with the draft 
work).  Am I correct?
So, if then the local repo is deleted and a new one created by cloning the main 
repo, we end up with the desired effect: a repo that does not include any 
‘bloat’ from the private work.
But, since many people (myself including) seem to like the idea of draft work 
that once merged into mainstream branches should no longer take up space 
(forever) in the repo, and given that the above procedure actually achieves 
this goal, wouldn’t be nicer to have an explicit command (or option to existing 
command) to purge a private branch at the local level?
(BTW, multiple check-outs is not the same.  You have to work with stash.  
Copying the repo file to take with you on another computer does not bring along 
the stash.  It also carries the risk of losing the stash if you accidentally 
delete the current directory.)
This would have the same effect as Git rebase (to some extent), wouldn’t it?
From: Scott Robison 
Sent: Wednesday, December 16, 2015 11:28 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Fossil mentioned on HN

On Wed, Dec 16, 2015 at 4:06 AM, Stephan Beal  wrote:

  On Wed, Dec 16, 2015 at 11:59 AM, Gaurav M. Bhandarkar 
 wrote:

"git rebase -i" seems to enable me to work on multiple projects at the same 
time. Because of it I can maintain versioned "development sessions" of not only 
my code but other things that were required/relevant to make that code. Without 
it I find it impossible to handle the "context switch" that comes when you work 
on multiple projects.


  fossil supports multiple open checkouts of any given repo db copy, which is 
arguably a cleaner approach than temporarily sticking stuff into SCM (when 
you've no intention of keeping it there). It's a matter of taste, of course, 
but fossil does offer an option other than keeping separate trains of thought 
in the same physical copy of the tree. To me that seems simpler than [ab]using 
the SCM for that type of thing, in particular because a context switch is a 
simple 'cd' instead of SCM commands.

I realize that 'get rebase -i' gives a lot more tools, but couldn't 99% of 
rebase use cases be handled with private branches? I've never used private 
branches until today (just for testing purposes), and from what I see I can do 
whatever I want in the private branch, merge from trunk, cherry pick, reverse 
out, whatever to make the tip of my private branch 100% pristine and proper, 
and only then merge it to trunk. I could just as easily have created a new 
branch off the tip of trunk,and merged my private branch to the public branch, 
which I could then merge to trunk so that people aren't upset at me for working 
on trunk.

-- 
Scott Robison 




___
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] BUNDLE problems/questions - resent to the correct list this time :)

[tonyp]

1. I’m trying to create a new repo by taking a branch from an existing one.  
So, I thought the easier way would be the new ‘bundle’ feature.

I tried this batch file (Win7):
-
f new xxx.fossil --date-override 2014-01-01
f o xxx.fossil
f bun export xxx --standalone --branch %1 –R original.fossil
f bun import xxx --publish --force
-

where %1 is replaced by the name of the branch I want to extract.  The 
--date-override is only there to place the initial empty commit before the 
imported content.  But, it makes no difference if I use it or not.

The problem: For some branch trying to “FOSSIL UPDATE branch” (from the initial 
empty trunk) works fine, and all the files are checked out.

Doing the exact same thing for a different branch, however, gives me:
content missing for ... each file ...
missing content, unable to update

If I use the UI I can see the file contents just fine.  So, the files are there 
but, for whatever reason, inaccessible.

What can be the cause of this?  Why does the above sequence of commands work 
for one branch but not another (from the same repo)?

2. Can I make the imported bundle end up in trunk without manually shunning the 
initial empty commit, and making the first node of the imported bundle branch 
the beginning of a new branch named ‘trunk’?

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

[fossil-users] Suggestion for local/global settings enhancement

[tonyp]

Certain settings, like ignore-glob or binary-glob can have a really long list 
of items, which may be edited from time to time.
Ideally, the global setting should have the ones that apply to all repos, while 
the local setting only the ones that apply only to that specific repo.

The problem is once you decide to use the local setting you need to specify the 
whole long list of items again for each repo.  And if you later change the 
global setting you need to remember to redefine all local settings for repos 
that include more items in the same setting to include the changes of the 
global setting.

My suggestion is this:

Have some form of shorthand notation – a text replacement macro, if you like – 
(like the string “~global~”, for example – or some other that is very unlikely 
to be an actual filename – or even something that is impossible to be a 
filename depending on the underlying OS), to let one import all the global 
settings for the given setting when specifying the local setting.

So, if the global setting is

binary-glob  (global) 
*.bin,*.bmp,*.com,*.dll,*.ico,*.exe,*.gif,*.jpg,*.mdb,*.mp3,*.mp4,*.obj,*.pdf,*.png,*.rar,*.jar,*.res,*.rtf,*.wav,*.zip,*.ppu,*.o

and the local setting needs to add to the above list just one item (*.pmp), one 
could do this:

fossil set binary-glob ~global~,*.pmp

(where ~global~ can appear anywhere, first, in-between, or last) and fossil set 
will display (in this case):

binary-glob  (local) 
*.bin,*.bmp,*.com,*.dll,*.ico,*.exe,*.gif,*.jpg,*.mdb,*.mp3,*.mp4,*.obj,*.pdf,*.png,*.rar,*.jar,*.res,*.rtf,*.wav,*.zip,*.ppu,*.o,*.pmp

However, the substitution of (macro) ~local~ should occur only at run-time so 
that a possible later update of the global setting will be automatically 
carried over to all local settings using ~global~

I hope I described this well enough to make sense.  I also hope you see the 
usefulness of what I’m proposing.  (Well, at least if you normally maintain 
more than just a few repos.)

Thanks.___
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] Why does the repo file grow over time?

[tonyp]

Funny thing is that for some repos, the file will shrink even further if you 
re-run the command a 2nd time.


-Original Message- 
From: Richard Hipp

Sent: Saturday, November 28, 2015 1:52 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Why does the repo file grow over time?

On 11/27/15, sky5w...@gmail.com  wrote:

Nice, I just recovered 50% file size using:
  fossil rebuild --compress-only
I had only ever used fossil rebuild and vacuum's?
Thanks for heads up.



Note that this works with the "all" command too:

   fossil all rebuild --compress-only

So you can shrink all of your repos down to their minimum size with a
single command.

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


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

Re: [fossil-users] Unexpected merge conflict

[tonyp]

But did you have to spoil our innocence?  :)

From: Stephan Beal 
Sent: Saturday, November 14, 2015 11:11 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

On Sat, Nov 14, 2015 at 2:14 AM,  wrote:

  f up ...

  f me ...

while i also use 'f' as a local fossil alias, it never, until now, occurred to 
me how inappropriate it sounds in conjunction with specific commands! ;)

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do." -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] Unexpected merge conflict

[tonyp]

Thanks for the detailed explanation.  It makes perfect sense now.   Certainly, 
a rather difficult task to get right algorithmically.
Many thanks also to all previous respondents.
From: Scott Robison 
Sent: Saturday, November 14, 2015 8:22 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

Thanks for this. It made it easy for me to visualize what is going on -- and no 
debugging was necessary! :)
...
I hope that explanation makes sense.

Perhaps it would make sense to modify the "common ancestor" line in the marked 
up merge file to call it the baseline? Or "BASELINE (often known as COMMON 
ANCESTOR)"? Or something along those lines...

-- 

Scott Robison___
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] Unexpected merge conflict

[tonyp]

I have to agree with your first four sentences.

Your prove-it-to-yourself example, however, is quite different from my case 
where all changes happened in the same branch, and trunk was unaltered (with 
respect to the lines in question).

Obviously, if the same line of code changes on both sides of the merge, this is 
a clear conflict.

But, in my case, only one side has changed.  (The conflict seems to arise from 
the changes occurring in the same branch and the inability to use all of them 
due to cherry picking.)

Because the cherry pick option was used, only those changes introduced in that 
particular check-in should be merged (i.e., compared with the other side of the 
merge).  But, fossil apparently sees the end result of that line as affected by 
previous check-ins even though cherry pick was used.  I now see this is a 
limitation of the merging mechanism that, apparently, can only deal with full 
line merges.  I guess we have to live with that.

However, I still feel there was a misleading (if not incorrect) report of the 
problem.  For one thing, the common ancestor content shown seems totally 
incorrect.  But then again, I have no clue which check-in fossil picked to be 
the common ancestor.  Maybe there could a report in that message of the 
check-in ID chosen as the common ancestor to help debug the issue.

A clearer conflict report like “Cherry-picked content carries previous 
check-ins” or “Cannot cherry pick this particular line” would also be nice.

From: Scott Robison 
Sent: Friday, November 13, 2015 6:40 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

On Nov 13, 2015 9:15 AM, "Tony Papadimitriou"  wrote:
>
> Sorry for the confusion.
> By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing 
> the merge.
> And, I’m merging the “check-in from the ... [other] branch”  I mean the 
> check-in which is part of the other part.
>  
> I think I’m beginning to understand what’s going on.  If I do a full merge 
> (no cherry pick) there are no conflicts.
> So, it seems the fact that the SRF_OUT label was renamed in an earlier 
> check-in that the one I’m cherry picking is confusing it.
> What should have happened actually (what I expected with the cherry pick) is 
> not exactly what I mentioned earlier.
> The ‘puts’ change being part of the check-in I cherry picked should have 
> merged in and the SRF_OUT rename (being from an older check-in) in the 
> development branch should have stayed out.
>  
> This is a conflict if you look at this line of code as one piece (i.e., you 
> either merge the whole line or none of it).

I believe with 99% confidence that you've hit the nail on the head. Merge is 
line based. It either merges one or a block of lines as a single entity. It 
doesn't deal with line fragments. To prove this to yourself, you could create a 
repo with a single file and a single line of text. Branch it an add a character 
to the end. Go back to trunk and create a new commit with an new character at 
the beginning of the line. Try to merge. The same line was modified in both 
branches so it isn't sure what to do.

I'm doing this from memory on my phone, so if I'm wrong, my apologies. And I'll 
be surprised! :)




___
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] Unexpected merge conflict

[tonyp]

The following Windows batch file will reproduce the condition I’m talking about 
(f = fossil):

f new sample.fossil
f o sample.fossil
echo Hello > hello.txt
f add hello.txt
f com -m Initial
echo Hello, World > hello.txt
f com --branch other -m "Added World!"
echo Computer said: Hello, World > hello.txt
f com -m "Added 'Computer said'"
f up trunk
f me other --cherrypick

From: Scott Robison 
Sent: Saturday, November 14, 2015 2:17 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Unexpected merge conflict

If it would be helpful, I'd be glad to take a look at your repo, or a 
fabricated repo that demonstrates the same issue. Without the actual current 
state of the repo, it's hard to know what the exact problem is. Hence my 
previous guesses. 

I didn't write the merge code, but I once upon a time thought I'd found a bug 
in it, and only several hours of running it under a debugger convinced me that 
my expectations were at fault, not fossil. I can't say for certain that your 
problem is the same, but that's what I'd guess.

On Fri, Nov 13, 2015 at 2:21 PM,  wrote:

  I have to agree with your first four sentences.

  Your prove-it-to-yourself example, however, is quite different from my case 
where all changes happened in the same branch, and trunk was unaltered (with 
respect to the lines in question).

  Obviously, if the same line of code changes on both sides of the merge, this 
is a clear conflict.

  But, in my case, only one side has changed.  (The conflict seems to arise 
from the changes occurring in the same branch and the inability to use all of 
them due to cherry picking.)

  Because the cherry pick option was used, only those changes introduced in 
that particular check-in should be merged (i.e., compared with the other side 
of the merge).  But, fossil apparently sees the end result of that line as 
affected by previous check-ins even though cherry pick was used.  I now see 
this is a limitation of the merging mechanism that, apparently, can only deal 
with full line merges.  I guess we have to live with that.

  However, I still feel there was a misleading (if not incorrect) report of the 
problem.  For one thing, the common ancestor content shown seems totally 
incorrect.  But then again, I have no clue which check-in fossil picked to be 
the common ancestor.  Maybe there could a report in that message of the 
check-in ID chosen as the common ancestor to help debug the issue.

  A clearer conflict report like “Cherry-picked content carries previous 
check-ins” or “Cannot cherry pick this particular line” would also be nice.

  From: Scott Robison 
  Sent: Friday, November 13, 2015 6:40 PM
  To: Fossil SCM user's discussion 
  Subject: Re: [fossil-users] Unexpected merge conflict

  On Nov 13, 2015 9:15 AM, "Tony Papadimitriou"  wrote:


  >
  > Sorry for the confusion.
  > By “merge from trunk” I mean I’m in branch ‘trunk’ and from there I’m doing 
the merge.
  > And, I’m merging the “check-in from the ... [other] branch”  I mean the 
check-in which is part of the other part.
  >  
  > I think I’m beginning to understand what’s going on.  If I do a full merge 
(no cherry pick) there are no conflicts.
  > So, it seems the fact that the SRF_OUT label was renamed in an earlier 
check-in that the one I’m cherry picking is confusing it.
  > What should have happened actually (what I expected with the cherry pick) 
is not exactly what I mentioned earlier.
  > The ‘puts’ change being part of the check-in I cherry picked should have 
merged in and the SRF_OUT rename (being from an older check-in) in the 
development branch should have stayed out.
  >  
  > This is a conflict if you look at this line of code as one piece (i.e., you 
either merge the whole line or none of it).
  I believe with 99% confidence that you've hit the nail on the head. Merge is 
line based. It either merges one or a block of lines as a single entity. It 
doesn't deal with line fragments. To prove this to yourself, you could create a 
repo with a single file and a single line of text. Branch it an add a character 
to the end. Go back to trunk and create a new commit with an new character at 
the beginning of the line. Try to merge. The same line was modified in both 
branches so it isn't sure what to do.

  I'm doing this from memory on my phone, so if I'm wrong, my apologies. And 
I'll be surprised! :)


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






-- 

Scott Robison 

Re: [fossil-users] symlinks (was Re: xkcd on git)

[tonyp]

Although I certainly agree with your point (and don’t care about symlinks 
myself, BTW), I’m afraid it’s a bit too late to expect portability of repos 
between platforms (mainly, Linux and Windows) without prior care from the repo 
maintainers.

Just the fact the Linux has case-sensitive filenames, and Windows does not, can 
make it impossible for a Linux repo to check-out in Windows correctly (if the 
Linux repo has two or more files in the same subdirectory that differ only in 
case).
From: Stephan Beal 
Sent: Thursday, November 05, 2015 9:18 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] symlinks (was Re: xkcd on git)

On Tue, Nov 3, 2015 at 7:59 PM, David Mason  wrote:


  It's simple: a symlink is a filesystem artifact and should be reflected as 
such in the repository.  It should not be followed; if foo is a symlink and I 
say "fs add foo/bar" it should probably give an error. (This might surprise 
people the first time, but it's easy to explain - foo/bar isn't part of the 
repo, regardless of where foo points.)


But it's not quite that simple, philosophically speaking: we expect Fossil to 
extract _exactly_ what we put in it, and that's not portably possible when it 
comes to symlinks. As soon as someone checks out your repo on a non-Unix 
system, fossil is creating output which you did not put in fossil. That's a 
tremendous psychological/philosophical hurdle for me. i'd rather live without 
symlinks than know that my repos check out differently depending on the 
platform.

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do." -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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 v1.34 unexpected CLEAN command changes from v1.33

[tonyp]

I built the latest version and (unfortunately, for me) CLEAN no longer asks for 
confirmation.

Is this something I can have behave the way it was in v1.33 via some setting?  
(I often do a clean but may want to skip some file, so I like to be asked.)

If not possible anymore, is there at least some way to see which files get 
cleaned (other than running with –n option in advance which would require 
running the clean command twice all the time – and remembering about it) so I 
can undo the specific one I want to keep?

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

[fossil-users] Question about MERGE

[tonyp]

Today I tried something and got an unexpected result.  So, I would like to know 
what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these 
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, I 
REVerted the files whose changes I did not want included yet (as they are not 
fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the rest 
of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?

Thanks.___
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] Question about MERGE

[tonyp]

OK, but doesn't cherry-pick work the same as a MERGE but only for single 
version of the timeline?


My intent was to get all changes from the branch (the whole history) but for 
specific files, only.


-Original Message- 
From: Richard Hipp

Sent: Wednesday, October 28, 2015 6:00 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Question about MERGE

On 10/28/15, to...@acm.org  wrote:

Today I tried something and got an unexpected result.  So, I would like to
know what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, 
I

REVerted the files whose changes I did not want included yet (as they are
not fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the
rest of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?



Cherry-pick the changes you wanted to import.

When you did "fossil merge" that told Fossil that your intent was that
everything in the branch had been integrated into the trunk.  You went
back and undid some of those changes using "fossil revert", but Fossil
understood that to be your intent - that you wanted to abandon those
changes.

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


___
fossil-users 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 close an empty branch?

[tonyp]

Very easy to reproduce (Win7, f = fossil):

f new sample.fossil
f o sample.fossil
echo Hello > somefile
f add somefile
f com --branch ghost -m "Save in some branch"
f tag cancel ghost af9e
rem The actual ID above may differ
f up ghost
rem not found: ghost
f bra
f up  --does not tell you the current branch
f up trunk
f bra
rem   ghost
rem * trunk

-Original Message- 
From: Richard Hipp 
Sent: Saturday, October 24, 2015 3:57 PM 
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to close an empty branch? 

On 10/23/15, Warren Young  wrote:
> Matt Welland’s recent post reminded me of a problem I’ve been ignoring in
> our largest Fossil repo, converted from ~12 years of CVS-then-SVN history.
>
> For some reason, that long history includes a branch that has no checkins,

How is that even possible in Fossil?  A branch is a property of a
check-in, and so without a check-in there can be no branch.  I think I
am not understanding your problem


> which means the Fossil UI doesn’t have anything you can click on to close
> the branch. Consequently, it shows up in all listings of open branches.
>
> I don’t see how to do it from the command line, short of “fossil sqlite”.
>
> How do I put this bulletproof vampire zombie down? :)
> ___
> 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___
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 can I get 'Check-ins' by default in timeline (instead of Any Type)?

[tonyp]

How can I get 'Check-ins' by default in timeline (instead of Any Type)?

Thanks.___
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 close an empty branch?

[tonyp]

I ran into the same problem just yesterday.  Took me a while to figure out a 
solution.  (And, this may not be the only way but it worked well.)

In my case there were two possibilities.  For one, I could just do 'unhide' and 
see the related timeline.
The other (like yours, probably) did not show anything.  I could not go into 
the branch (by update or open directly into it), or, in general, see anything 
about it; a real ghost!  The problem as it turned out was the only tag 
associated with it was canceled leaving without any tags.  So, I did:

fossil sea cancel tag
(shows all cancel tag related entries.  Find the ID of the one I need by 
looking at the tags for each entry)
>From the UI, find the related artifact (the one that cancels the tag), and get 
>its full ID and shun it, then rebuild.
This will bring the branch back to life, and then you can close it, hide it, 
etc.

-Original Message- 
From: Warren Young 
Sent: Saturday, October 24, 2015 2:35 AM 
To: Fossil SCM user's discussion 
Subject: [fossil-users] How to close an empty branch? 

Matt Welland’s recent post reminded me of a problem I’ve been ignoring in our 
largest Fossil repo, converted from ~12 years of CVS-then-SVN history.

For some reason, that long history includes a branch that has no checkins, 
which means the Fossil UI doesn’t have anything you can click on to close the 
branch. Consequently, it shows up in all listings of open branches.

I don’t see how to do it from the command line, short of “fossil sqlite”.

How do I put this bulletproof vampire zombie down? :)
___
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] How to close an empty branch?

[tonyp]

This makes wonder.  Is there any practical reason to allow a check-in without 
any tags?
If not, maybe a warning should be issued when trying to cancel the only 
remaining tag of a check-in.

From: to...@acm.org 
Sent: Saturday, October 24, 2015 11:19 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to close an empty branch?

I ran into the same problem just yesterday.  Took me a while to figure out a 
solution.  (And, this may not be the only way but it worked well.)

In my case there were two possibilities.  For one, I could just do 'unhide' and 
see the related timeline.
The other (like yours, probably) did not show anything.  I could not go into 
the branch (by update or open directly into it), or, in general, see anything 
about it; a real ghost!  The problem as it turned out was the only tag 
associated with it was canceled leaving without any tags.  So, I did:

fossil sea cancel tag
(shows all cancel tag related entries.  Find the ID of the one I need by 
looking at the tags for each entry)
>From the UI, find the related artifact (the one that cancels the tag), and get 
>its full ID and shun it, then rebuild.
This will bring the branch back to life, and then you can close it, hide it, 
etc.

-Original Message- 
From: Warren Young 
Sent: Saturday, October 24, 2015 2:35 AM 
To: Fossil SCM user's discussion 
Subject: [fossil-users] How to close an empty branch? 

Matt Welland’s recent post reminded me of a problem I’ve been ignoring in our 
largest Fossil repo, converted from ~12 years of CVS-then-SVN history.

For some reason, that long history includes a branch that has no checkins, 
which means the Fossil UI doesn’t have anything you can click on to close the 
branch. Consequently, it shows up in all listings of open branches.

I don’t see how to do it from the command line, short of “fossil sqlite”.

How do I put this bulletproof vampire zombie down? :)
___
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

Re: [fossil-users] MERGE problem (with renames/deletes)

[tonyp]

I’ve been reading much of this discussion so far, and although it has focused 
primarily on the possibility of a deleted file not merging in as one may have 
expected, I have to say that my report was not about that.

What I reported had to do with the addition of new files in trunk that were 
never present in the other branch, then merging trunk from the other branch 
does not bring in the newly added files.  By newly added, I don’t mean in the 
last commit.  It may have been tens of commits earlier but they are new in 
relation to the other branch which is updated much less frequently.

Unfortunately, I cannot provide the repo for examination.

Anyway, I finally manually updated the files and went on with life.  But, I’m 
sure there is a bug somewhere in that behavior I’ve seen, and it’s certainly 
not related to files being deleted from either branch.

BTW, irrelevant to my particular case, but I would expect any addition a file 
(even after that file had been deleted in previous check-ins) to be seen as a 
new file, because that’s what it really is.  So, delete or no delete, a newly 
introduced (or re-introduced) file should be merged because it is wanted change.

Thanks.
___
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 LS bug?

[tonyp]

With this setting:
relative-paths   (local)  1

doing FOSSIL LS .
from within a subdirectory displays the full path (from the root or the repo).

I tried with older version and current trunk and get the same behavior.
___
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] diff after update

[tonyp]

Although I think --undo is not too bad as it clearly does not make sense to 
'undo' a diff, another alternative that is less 'verbal' that might work is


diff --back  (as in "diff with what would be there if I were to go back, or 
back out the recent changes...")


-Original Message- 
From: Richard Hipp

Sent: Friday, September 11, 2015 8:27 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] diff after update

On 9/11/15, Warren Young  wrote:


diff --undo sounds like you’re asking it to undo the diff, which makes no
sense.


I agree.  I'm just having trouble coming up with an alternative.



How does “fossil diff --last” strike you?


Still a little generic, I think, but moving in the right direction.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


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

Re: [fossil-users] Automatically put version / checkout infomation into source code on commit

[tonyp]

To get the checkout version into your app, one way (I've been using 
successfully) is this:


With the help of a little script (like the following Lua one) extract the 
checkout version into a file that is included from your app.
This file is generated as part of the make build process and is itself not 
part of the repo, i.e., 'fossil clean' removes it.


(You'll have to change the fo:write(...) line according to your 
requirements.)


--==
-- Creates checkout.inc file for including Fossil checkout version in source
--==

function run(cmd)
 assert(type(cmd) == 'string','cmd should be the string of the command to 
run')

 print('Running...',cmd)
 local f = io.popen(cmd)
 local ans = f:read('*a')
 f:close()
 return ans
end

ans = run('f tim current')

fo = io.open('checkout.inc','w')
for line in ans:gmatch('%[(%x+)%].+%*CURRENT%*') do
 fo:write(fcc   ' * ..line..')
end
fo:close()

--==

-Original Message- 
From: Michael Weise

Sent: Monday, July 13, 2015 10:45 AM
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Automatically put version / checkout infomation into 
source code on commit


Dear all,

we've been using fossil for over a year now and are quiet happy with it.

The next thing we'd like to do is to automatically put some version
infomation from the fossil repository into the sourcecode. This will
help us to know which checkout version was used for a specific build /
executable.

1. Is this possible with fossil?
2. What approach can you recommend?

Thanks,
Michael


PS: Programming language used is C++
___
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 UPDATE behavior -- feature or bug?

[tonyp]

Using the UPDATE command, when trying to bring in a subdirectory from another 
version (I tried both from a different branch and from the same branch and I 
get the same behavior), and that subdirectory does not exist in the current 
version, nothing happens saying “changes:  None. Already up-to-date”.

But, if you manually create the needed subdirectory first, and try again, it 
works!

This looks like a bug to me.  To reproduce (Win machine commands between dotted 
lines) where f = fossil:

-
f new sample.fossil
f o sample.fossil
md a
dir  a\a
f add a
f com -m Dir A
md b
dir  b\b
f add b
f del a
rd a/s/q
f com -m Dir B --branch other
f close
f o sample.fossil other
f up trunk a
rem Here nothing happened!!!  But if I continue like this:
md a
f up trunk a
rem Success!!
-

I tried with these versions:

This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
UNICODE_COMMAND_LINE

and with:

This is fossil version 1.33 [e2411525c1] 2015-06-05 18:07:02 UTC
Compiled on Jun  6 2015 14:43:59 using msc-18.00 (32-bit)
SQLite 3.8.11 2015-05-29 17:51:16 db4e9728fa
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
UNICODE_COMMAND_LINE

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

[fossil-users] WARNING: multiple open leaf check-ins on trunk:

[tonyp]

I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
UNICODE_COMMAND_LINE

Doing a FOSSIL UP TRUNK command gave me this today:

WARNING: multiple open leaf check-ins on trunk:
  (1) 2015-05-29 17:48:57 [eba9fa6147] (current)
  (2) 2014-11-05 13:36:22 [91ef16c613]

Trying the same with this previous fossil version I used:
This is fossil version 1.32 [6c40678e91] 2015-03-14 13:20:34 UTC
Compiled on Apr 11 2015 16:16:04 using msc-18.00 (32-bit)
SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
UNICODE_COMMAND_LINE

gives no problems!

Is my repo corrupt or what’s wrong with the new (or the old) version?

My timeline looks fine.

Thanks.___
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] WARNING: multiple open leaf check-ins on trunk:

[tonyp]

(BTW, this is a private repo).

So, if this is a new feature, it means the problem was there all along and I 
simply now found out about it!  Great!

What I see at that time is the following (I hope the image won’t disappear – if 
it does, get it here: https://www.dropbox.com/s/ozzicm164dc2o0d/fork.png?dl=0):



Check-in d137 was originally trunk but moved to a branch ‘mistake’.  (I guess 
shunning would have been a better solution at the time, but too late now, 
right?)

91ef is trunk, and e096 is trunk, but there is no direct link between them, 
only through d137.  Is this considered a fork even though there is no duplicate 
trunk timeline?  It’s more like a ‘discontinuous‘ trunk.

What I wanted to do at the time was to make d137 disappear completely.  But, 
(if I’m not mistaken, based on advice I had received possibly on this list – at 
least the way I had understood it), moved it to branch ‘mistake’ to make it 
invisible from trunk.  So, now I’m stuck with a warning?

Is there a way to re-connect 91ef to e096 without going via d137?  Or, even to 
re-instate d137 as trunk, if no better way?

Thank you.

-Original Message- 
From: Richard Hipp 
Sent: Friday, May 29, 2015 9:24 PM 
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk: 

On 5/29/15, to...@acm.org to...@acm.org wrote:
 I updated to this recent version of fossil:
 This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
 Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
 SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
 Schema version 2015-01-24
 zlib 1.2.8, loaded 1.2.8
 SSL (OpenSSL 1.0.2a 19 Mar 2015)
 UNICODE_COMMAND_LINE

 Doing a FOSSIL UP TRUNK command gave me this today:

 WARNING: multiple open leaf check-ins on trunk:
   (1) 2015-05-29 17:48:57 [eba9fa6147] (current)
   (2) 2014-11-05 13:36:22 [91ef16c613]

Bring up fossil ui then move your browser to
http://localhost:8080/timeline?c=2014-11-05 and you'll see the fork.

This is a new feature of Fossil, not a bug.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Linux compilation problem (Ubuntu v14) and is rebuild needed?

[tonyp]

OK, got it working with these 3 steps:
make clean
./configure
make


   Q2:  Do I need a rebuild after going to v1.33 from v1.32?


Regarding Q2 I meant is a FOSSIL REBUILD required when going from 1.32 to 
1.33?


Although it seems the database schema hasn't changed from fossil v1.32 
(based on fossil ver -v) I'm not sure if alone is enough to avoid a REBUILD.


Thanks.

-Original Message- 
From: Martin Gagnon

Sent: Saturday, May 23, 2015 4:53 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Linux compilation problem (Ubuntu v14) and is 
rebuild needed?


On Sat, May 23, 2015 at 04:27:31PM +0300, to...@acm.org wrote:

   Q1: How do I solve this?  (I have already tried ./configure and didn’t
   make any difference)

   ./bld/piechart.o: In function `piechart_render':
   ./src/piechart.c:176: undefined reference to `sincos'
   ./src/piechart.c:179: undefined reference to `sincos'
   ./src/piechart.c:191: undefined reference to `sincos'
   collect2: error: ld returned 1 exit status
   make: *** [fossil] Error 1


It works for me on ubuntu 14.04LTS.

Seems that you have a linkage problem (not compilation), look like it
didn't link against libm. On the last line before the error (where you
see a bunch of .o files one after the other. Do you see -lm at the
end ?



   Q2:  Do I need a rebuild after going to v1.33 from v1.32?


May be I'm a bit too parano, but every time I build from source after an
update I do a make clean and a ./configure.

 $ fossil up
 $ make clean
 $ ./configure
 $ make


--
Martin G.
___
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] Linux compilation problem (Ubuntu v14) and is rebuild needed?

[tonyp]

Q1: How do I solve this?  (I have already tried ./configure and didn’t make any 
difference)

./bld/piechart.o: In function `piechart_render':
./src/piechart.c:176: undefined reference to `sincos'
./src/piechart.c:179: undefined reference to `sincos'
./src/piechart.c:191: undefined reference to `sincos'
collect2: error: ld returned 1 exit status
make: *** [fossil] Error 1

Q2:  Do I need a rebuild after going to v1.33 from v1.32?

Thanks.___
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 [f4aed6661c] compilation problem MSVC

[tonyp]

..\src\piechart.c(145) : error C2065: 'M_PI' : undeclared identifier
..\src\piechart.c(157) : error C2065: 'M_PI' : undeclared identifier___
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 [f4aed6661c] compilation problem MSVC

[tonyp]

Yes, it now works.  Thanks.

BTW, if you're also interested in some long-standing warnings (with MSVC 
again), here they are:


..\src\url.c(459) : warning C4090: 'function' : different 'const' qualifiers
..\src\url.c(460) : warning C4090: 'function' : different 'const' qualifiers
..\src\url.c(485) : warning C4090: 'function' : different 'const' qualifiers
..\src\url.c(486) : warning C4090: 'function' : different 'const' qualifiers
zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _free imported 
in function _zcfree
zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _malloc 
imported in function _zcalloc


(If these are resolved, then it will be a zero-warning compilation under 
MSVC.)

I compile with SSL support, if this matters for any of the above.

-Original Message- 
From: Richard Hipp

Sent: Saturday, May 09, 2015 8:59 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Fossil [f4aed6661c] compilation problem MSVC

On 5/9/15, to...@acm.org to...@acm.org wrote:

..\src\piechart.c(145) : error C2065: 'M_PI' : undeclared identifier
..\src\piechart.c(157) : error C2065: 'M_PI' : undeclared identifier


Should be fixed now.  Thanks for the report.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


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

[fossil-users] FOSSIL STASH wish list

[tonyp]

To add to the perpetual wish list:

Can the STASH [SAVE] command be made to behave similarly to the COMMIT command 
with respect to comments in the editor?
That is, if nothing is typed as stash comments, the stash operation to be 
aborted.

It currently does not allow one to abort, and if you don’t, you end up with a 
‘mystery’ stash entry which is kind of useless if you can’t remember what that 
was about.
(Currently, you can of course undo with a STASH POP right after you mess up, 
and re-do by adding a comment but I think the proposal would save time.)

Thanks.
___
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] Branch only timeline

[tonyp]

+1 (wish list)

I don't think there is as I had asked for the same quite some time ago.

But, I guess an option like -b [branch] could be added eventually to do 
this.  (Similar to how -p can be used to filter by given file/dir name.)
Example: -b without an explicit branch name to show timeline only for 
current branch.


-Original Message- 
From: Ron Aaron

Sent: Thursday, April 23, 2015 10:01 AM
To: Fossil SCM user's discussion
Subject: [fossil-users] Branch only timeline

Is there a way to restrict the timeline to a specific branch?

fossil help timeline didn't show anything...
___
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] Bug? FOSSIL MV does not work as expected (Win7machine)

[tonyp]

I’m aware of the “within the repository”, and actually I’m not among those who 
are so interested in this changing this, as proposed by others.  So, not the 
same issue here.

What I’m reporting is unrelated to changes happening on disk.  If you run the 
example below you should not be allowed to close the repo since there are 
uncommitted changes (the mv).  But, since nothing actually happened, and that 
exactly is the problem I’m seeing, you can close it normally (without –force).

This looks like a bug to me.
From: Michael Richter 
Sent: Tuesday, April 21, 2015 11:24 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Bug? FOSSIL MV does not work as expected 
(Win7machine)

The key wording there is within the repository tree. 

It doesn't change the file system, only the naming of the files, etc. in the 
repository.  Whether this is desired or correct behaviour is … an area of 
frequent discussion.

My own response to that discussion is to use the fsl wrapper 
(http://fossil.0branch.com/fsl/home) and make it do whatever I expect it to do.

On 17 April 2015 at 21:48, Tony Papadimitriou to...@acm.org wrote:

  This is on a Win7 machine (if it matters).  A simple way to reproduce (f = 
fossil):

  f new xxx.fossil
  f o xxx.fossil
  mkdir a\a
  dir  a\a\xxx
  f add a
  f com -m Initial
  f mv a\a b
  f close

  Based on help screen, and usual behavior of mv, I would expect subdirectory 
a\a to be now known as b, and of course all files below to move accordingly.  
But nothing happens.  If I move each file separately, it works.

  This is what the help screen shows:

  Usage: f mv|rename OLDNAME NEWNAME
 or: f mv|rename OLDNAME... DIR

  Move or rename one or more files or directories within the repository tree.
  You can either rename a file or directory or move it to another subdirectory.


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






-- 

Perhaps people don't believe this, but throughout all of the discussions of 
entering China our focus has really been what's best for the Chinese people. 
It's not been about our revenue or profit or whatnot.
--Sergey Brin, demonstrating the emptiness of the don't be evil mantra.



___
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] Can fossil be used to apply a diff patch?

[tonyp]

Can fossil be used to apply a diff patch (such as that created by the diff 
command)?___
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] Can fossil be used to apply a diff patch?

[tonyp]

Thank you but I wanted this for a Win7 machine, not Linux.
(I have MINGW installed but its 'patch' is a bit unstable as it crashes most 
of the time besides not being available on most Win7 machines.)


That's why I was hoping fossil would be able to eat its own ... diff

Bundle is not good when the patch comes from a 3rd source (e.g., posted on a 
web site) in unified diff format, and there's nothing you can do about it.


Thanks, anyway.  I guess I need to look for a reliable Win7-based 
stand-alone patch utility.  Until then, manual editing! :)


-Original Message- 
From: Warren Young

Sent: Saturday, April 18, 2015 12:31 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Can fossil be used to apply a diff patch?

On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote:


Can fossil be used to apply a diff patch (such as that created by the diff 
command)?


Fossil itself doesn’t do that.  You use the patch(1) utility for that, which 
expects a unified diff.  (“fossil diff” produces output in that format by 
default, but diff(1) does not.)


If you want something that works entirely with Fossil tools, you should be 
using the new “bundle” features.  This creates a “sub-repository” containing 
a given change set, including all of the details Fossil tracks that do not 
appear in “fossil diff” output.

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

[tonyp]

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


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

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

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

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

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

Zoltan

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

Re: [fossil-users] Two trunks?

[tonyp]

But, what if the two forks become incompatible when merged?  For your proposed 
auto-merge to work, it’s enough that the two forks simply touch (alter) 
different files.

An auto-merge would obviously work without producing conflicts as neither fork 
touches files touched by the other fork.

Now, it’s quite possible that either fork which built OK before the merge, no 
longer does.

The simplest example is to consider as a sole change the addition of a new file 
in fork 2 which depends on an external function name called xxx().  Fork 1, 
however, has just changed that function from xxx() to yyy().  Neither fork will 
compile anymore (assuming the new file is now part of the build process).
It seems that merging can only be done manually, as only a human can know the 
implications of the changes in the merged files.
Disclaimer: I may have misunderstood your suggestion.

From: Matt Welland 
It would be very cool if on update if a fork was detected it was (optionally) 
automerged. If the merge had conflicts then it would be rolled back and the 
user notified.

Forks in fossil are an artifact of a distributed system trying to pretend it is 
centralized. Auto fork correction might help maintain the illusion of being 
centralized.___
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] Version 3.8.9 is in testing

[tonyp]

Just in case this was not intentional.  I have received this only from the 
Fossil list(s), but not SQLite's.


BTW, the introduction of the .dbinfo shell command made the more commonly 
used .dump come later and now needing more than just .d to invoke it. 
Bummer :(


-Original Message- 
From: Richard Hipp

Sent: Thursday, April 02, 2015 3:23 PM
To: fossil-dev ; fossil-users
Subject: [fossil-users] Version 3.8.9 is in testing

We have begun to mark off checklist items for the 3.8.9 release at
https://www.sqlite.org/checklists/3080900/index - the release will
occur when the checklist goes all green.  If you have any last-minute
concerns about the current state of the code, please bring them up
soon.

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


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

Re: [fossil-users] New timeline display options

[tonyp]

+1

-Original Message- 
From: Andy Bradford 
Sent: Tuesday, March 31, 2015 7:20 PM 
To: Matt Welland 
Cc: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New timeline display options 


Thus said Matt Welland on Mon, 30 Mar 2015 21:08:49 -0700:


+1 circular nodes, +1 colored  lines, seemed to make visually tracking
the branch easier to my eyes. but as Brad said, a matter of style.


Definitely a  matter of style. While  I think both are  pretty, I prefer
black edges  (the nodes are  already colored  and align nicely  with the
commit messages, and  I find the colored lines  distracting), and square
nodes. :-)

Andy
--
TAI64 timestamp: 4000551ac96a
___
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] Minor bug that causes some confusion

[tonyp]

This is on a Windows machine so, filenames are case insensitive.

To reproduce (f = fossil):

f new xxx.fossil
f o xxx.fossil
echo Hello  hello
f add hello
f cha
f ext
f rev Hello
f cha
f ext

Problem 1: “f rev Hello” does not revert the ADD (note: Hello is given with a 
different case from the previously added “hello” but on a Windows system this 
should not matter).  I assume this behavior is related to the name mismatch due 
to wrong use of case-sensitive comparison under Windows.

Problem 2: The REVERT command always says “UNMANAGE: filename” even when it 
does nothing.  Combined with the previous problem, this is misleading.  Saying 
UNMANAGE for any random filename when that filename is not part of the repo (or 
even the disk) is also wrong in itself.

Thanks.
___
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] Select specific changes within files

[tonyp]

++1

From: Scott Robison 
Sent: Friday, March 20, 2015 11:08 PM

On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich s...@stef.rs wrote:

  If we are discussing partial, I'm more interested in partial checkouts than 
partial commits, i.e. having the ability to checkout a specific directory only. 
Now that would be useful for us with big source trees where there are third 
party components included.


+1

-- 

Scott Robison 




___
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] Is this a crazy idea?

[tonyp]

I was about to suggest the same because I often have this situation, also.  I 
need to commit a large number of files, except one or two which are still no 
ready for commit.

I’ve been thinking about what the simplest way from a user’s point of view 
would be, and I think if in the editor that comes up for putting a commit 
comment, and all the files are listed underneath, the ability to simply put a 
minus before that file you do NOT want, or maybe just delete that line 
altogether, that would be very easy.   It also allows to verify which files get 
committed and which not at the last moment, making whatever changes in case of 
mistakes.

On the command line, an –ignore option would also be nice for the case –m is 
also supplied in which case the editor is not entered at all.

From: Abilio Marques 
Sent: Friday, March 20, 2015 2:52 AM

I've found myself in several other situations where I want to add everything 
except 1 or 2 files... So a commit --ignore these files would become handy. 
Specially because I can continue to do complete commits (of different files) 
while ignoring the same two, by repeating the command line on history, no 
changes at all, without having to think too much each time.
___
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] Timeline graph display options

[tonyp]

Although both are good, my vote is for nomo=0 (choice 1) as being the one 
that 'goes to 11' :)


-Original Message- 
On Mon, Mar 09, 2015 at 11:06:59PM -0400, Richard Hipp wrote:

Which timeline graph do you prefer:

(1) https://www.fossil-scm.org/fossil/timeline?y=cinomo=0
(2) https://www.fossil-scm.org/fossil/timeline?y=cinomo=1

The difference is in the merge lines.  Other examples:

(1) https://core.tcl.tk/tk/timeline?y=cinomo=0
(2) https://core.tcl.tk/tk/timeline?y=cinomo=1

(1) https://www.fossil-scm.org/fossil/timeline?y=cib=2015-02-26nomo=0
(2) https://www.fossil-scm.org/fossil/timeline?y=cib=2015-02-26nomo=1

The current default display is as in (1).  When there are many
parallel branches in a graph, Fossil reduces the spacing between the
vertical lines of the graph (called rails in the code) and when the
rails get really close together, Fossil automatically switches to
style (2) because that is clearly easier to read when the graph is
scrunched together.  (See, for example,
https://www.fossil-scm.org/fossil/timeline?y=cirailpitch=11).  But
after making that enhancements, I notice that style (2) seems less
cluttered, and so now I'm wondering if it ought to be the default.


___
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] Justification for two-step mv and rm

[tonyp]

You could always have a global setting on how to deal with this (old way vs 
new way) to keep everyone happy :)


-Original Message- 
From: Richard Hipp

Sent: Tuesday, March 03, 2015 11:22 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Justification for two-step mv and rm

On 3/3/15, Warren Young w...@etr-usa.com wrote:
Is there a good reason that “fossil mv” and “fossil rm” must be followed 
by

OS-level mv and rm commands?  I miss the behavior of Subversion which made
these into a single step.


When I have suggested changing this, I got push back that the change
will break existing scripts.

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


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

[fossil-users] Fossil's reported app name under Windows firewall

[tonyp]

I was trying to modify firewall settings for fossil to work as server under 
Windows 7, and (even after adding fossil.exe again and again) I couldn't 
find any program named fossil or even containing the word fossil in the list 
of firewall enabled apps.  To make a long story short, after lots of fooling 
around, I finally located it under this unsuspecting name:


Simple, high-reliability, distributed software configuration management 
system.


Yes, this whole thing.  It seems more like an advertisement for an unnamed 
product than an application name.  But if you must keep it this long, can 
you at least make it just a bit longer by adding the word Fossil in the 
beginning to make it easier to locate?


Thanks.

___
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] New search features

[tonyp]

https://www.dropbox.com/s/vujnqzgx3iaiu64/fossil.exe?dl=0

From: Richard Boehme 
Sent: Tuesday, February 03, 2015 1:58 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New search features

Does anyone have a Windows binary of the latest fossil with search? I don't 
have the ability to compile it from where I am at the moment.

Thanks.

Richard


On Tue, Feb 3, 2015 at 1:41 AM, jungle Boogie jungleboog...@gmail.com wrote:

  Dr. Hipp,
  On 2 February 2015 at 22:11, Richard Hipp d...@sqlite.org wrote:
   On 2/3/15, jungle Boogie jungleboog...@gmail.com wrote:
  
   Something recently has changed that doesn't allow the clicked result
   to be viewed.
  
   http://fossil-scm.org/index.html/tktsrch?s=windows
  
  
   The main Fossil repo (and the main SQLite repo) are now running on a
   full-text index, rather than do a full scan of all documents for each
   search.  This is faster, but considerably trickier to implement.  I
   expect it to be a bountiful source of errors over the next few days.

  Not a problem with me, I'll report them as I encounter them!

  
   The problem with hyperlinks is now fixed, I think.  Please try again.

  Yes, that corrected it and results are now clickable.

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

  Thanks!

  --
  ---
  inum: 883510009027723
  sip: jungleboo...@sip2sip.info
  xmpp: jungle-boo...@jit.si

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




-- 

Thank you.

Richard Boehme

Email: rboe...@gmail.com
Phone: 443-739-8502
Work Phone: 410-966-6606 (Mon - Thu 6 AM - 4:30 PM)



___
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] Windows 'make' broken?

[tonyp]

I tried to compile the latest fossil with SSL, and failed with the following 
errors:

cl -DOPENSSL_NO_SSL2 -DOPENSSL_NO_SSL3 /Fotmp32\cversion.obj  -Iinc32 -I
tmp32 /MT /Ox /O2 /Ob2 -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -
DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECA
TE -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPEN
SSL_NO_DYNAMIC_ENGINE /Zl /Zi /Fdtmp32/lib -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WIN
32 -c .\crypto\cversion.c
cversion.c
.\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier
.\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in le
vels of indirection from 'int'
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0
\VC\BIN\cl.EXE' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'pushd' : return code '0x2'
Stop.


The last version I tried to compile before that was [4c803826ad] and it was 
successful.  (I have updated to openssl-1.0.1k.tar.gz)
My make command: nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_BUILD_SSL=1

Any ideas?___
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] File age in the tree view

[tonyp]

Just to note that on Win7 (Firefox browser – if it matters), the mouse-over 
shading is so faint that if I hadn’t read about it here I wouldn’t have noticed 
it at all.

Can you make it a little more visible?___
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 force text for all files?

[tonyp]

How about this idea?

During 'commit' when asked

file contains binary data. Use --no-warnings or the binary-glob setting 
to disable this warning.

Commit anyhow (a=all/y/N)?

to have one more option (Text) to override the automatic detection. 
Something like:


file contains binary data. Use --no-warnings or the binary-glob setting 
to disable this warning, or force as text

Commit anyhow (a=all/t=text/y/N)?

Once a file is added as text (or binary, if the user chooses to accept the 
auto-detected binary status), subsequent commits should use the same mode 
for this file to avoid repeated prompting on each commit.   (I don't know if 
this status is saved someplace inside the repo, or recalculated each time it 
is needed.  If it is saved, the implementation should be simple.)


-Original Message- 
From: Martin Gagnon

Sent: Monday, December 08, 2014 11:09 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How to force text for all files?

On Mon, Dec 08, 2014 at 03:28:30PM -0500, Richard Hipp wrote:



On Mon, Dec 8, 2014 at 3:22 PM, bch brad.har...@gmail.com wrote:

Does the mode (text/binary) factor into the sha1 fingerprint hash of
an artifact (single file) or commit ?



No.  The mode is only used to determine how to display the content on a
webpage.  Also, independent changes can only be merged in text files, not
binary files.  And diff will only work for text files.

For the last two points - merge and diff - you can tell Fossil that the 
file is

text all you want, but if it really is binary that isn't going to make the
merge and/or diff algorithms work any better.  You will still end up with 
a

mess.




So what is the point of this?


For what I understand from the OP, it's only for convenience to be able
to call fossil diff/gdiff on a file that is mostly text but is
detected as binary by fossil.


Why is the default text/binary detection not working for Tony?


Andy analyse the OP file:
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg18304.html

Seems to be because there's some control and null characters in the file.

For myself, I like the fact that fossil detect the binary files by
itself, it save me a lot of time, especially on repository with a lot
files. But I think it would be good to have either a kind of
text-glob setting or at least a flag to the diff/gidff command to force
the diff to happens.

--
Martin G.

___
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] How to force text for all files?

[tonyp]

I'm not sure about the exact characters that may be causing this as each file 
has different ones.  (What characters would make the file binary in fossil’s 
eyes?)

I'm dropping a zip with two examples here 
(www.dropbox.com/s/bmjp65hfcv1ex9w/text_or_bin.zip?dl=0) that I happened to use 
lately, but the problem has occurred several times before with different files 
(not different sources and different content) but at this time I don't remember 
which ones (without extensive searching through my fossils) to give you more 
varied examples.

The problem: A (mostly) text file with just a few normally non-text chars which 
confuse fossil into thinking the whole file is binary.  I don’t know what 
heuristics fossil uses to determine that but they need improvement.

Regardless, may I ask, why do we even need automatic binary detection when the 
binary-glob setting exists?  And, even if a random binary file is ‘mistakenly’ 
saved as text (because it does not match binary-glob), isn’t the delta feature 
going to work to our benefit?  I mean, if the differences are too many, the 
whole file will be stored as is anyway, else only the deltas, correct?  So, on 
average this would save space even for binary files, no?  Nevertheless, in my 
case, the opposite happens, a text file whose content changes very little from 
version to version ends up being stored completely because it’s treated as 
binary.  But that’s only an academic issue for now as the files (in my case) 
are small.

The real problem is that once a file is treated as binary I can not ‘diff’ it 
between versions.

Thanks.

-Original Message- 
From: Andy Bradford 
Sent: Sunday, December 07, 2014 3:32 AM 
To: to...@acm.org 
Cc: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to force text for all files? 

Thus said to...@acm.org on Sat, 06 Dec 2014 22:23:33 +0200:

 One common  (for me) example is  a text file that  includes maybe just
 one or two  special 8-bit ASCII codes. This causes  the whole files to
 be stored as binary and makes it impossible to `diff'.

I committed some files  with è (which is 0xe8) in  them and Fossil shows
the diff between  the files. I do  get a warning that  the file contains
invalid UTF-8 characters when committing,  but it doesn't have a problem
diffing it.

What exactly are the characters (if you can say)?

Thanks,

Andy
-- 
TAI64 timestamp: 40005483ae33

___
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 force text for all files?

[tonyp]

No irony at all.  Certainly a file is either *assumed* to be text or binary, 
not both at the same time.  But isn’t ‘binary’ (or ‘text’) a matter of 
perspective/interpretation?  I don’t know of any formal definition or 
international standard of what constitutes ‘binary’ or ‘text’ files.  For 
example, since CR’s are not expected in Linux text files (unlike with Windows), 
having them in your file makes it binary instead of text?

I could claim that a file containing all 256 ASCII codes is a text file for my 
use.  On the contrary I could also claim that a file containing the string 
‘Hello’ is binary because of how it is treated by my app.  Maybe it’s an 
accidental display of a certain integer pattern.  At any rate, the distinction 
seems less important these days when most ‘text’ editors can load and let you 
edit practically any file, regardless of content.  In the old days, text 
editors would usually choke if there were given binary files.

To clarify, by ‘mostly’ I meant that even though looking at a file with a text 
editor you can easily determine the file is text, there may be a couple of 
characters inside it that do not conform to what most (?) people would expect 
in a text file.  However, is that enough to claim the file is not text when 
‘obviously’ it is (i.e., you can read it in a text editor and just skip over 
the couple of few funny looking special characters)?

From: Stephan Beal 
Sent: Sunday, December 07, 2014 8:35 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to force text for all files?

On Sun, Dec 7, 2014 at 6:55 PM, to...@acm.org wrote:

  The problem: A (mostly) text file with just a few normally non-text chars 
which confuse fossil into thinking the whole file is binary.

There's an irony in there somewhere. It can't be partly binary, it is either 
entirely binary or not binary. i.e. 0 or 1. There is no middle ground (in the 
world of integers).

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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 force text for all files?

[tonyp]

-Original Message- 
From: Will Parsons



And how could one possibly distinguish a file containing all 256 byte
bit patterns from a binary file?


That's the point, in effect you can't.  It's up to you to decide how to 
interpret a file.


Referring to all 256 ASCII codes is a misnomer.  There is *no* *such* 
*thing* as 8-bit ASCII, and using that term is a source of confusion.


Fine detail if you want to pedantic but irrelevant to the issue!  I should 
have said all possible 8-bit values because whether you decide to interpret 
them as ASCII or EBCDIC or whatever is another matter.
So, we can limit the problem to the actual 7-bit ASCII or change ASCII to 
EBCDIC and keep it 8 bits.  Now, if you have a file containing bytes values 
between 0 and 127, is the file binary or text?  There is no correct answer, 
is there?



using the term 8-bit ASCII indicates a fundamental misunderstanding.


Actually, the term 8-bit ASCII is very commonly used (even if it is not 
pedantically correct), although you still need to know the code page to use 
for the upper half of the codes, but it usually refers to ISO Latin-1.


It certainly could be.  Given an arbitrary block of bits, there is no 
certain way to determine whether it is
intended as text or not without knowing what encoding is being used for 
text.


Agreed.

Since SQLite (which underlies Fossil) uses UTF-8 encoded Unicode (which 
includes [7-bit] ASCII as a subset)
as its text encoding, *any* byte that is not part of a UTF-8 encoding makes 
the file binary, whether

you intended it to be or not.


I don’t think so.  SQLite is just a storage medium.  Its job is to save what 
I give it, not to interpret its meaning.
So, if SQLite decided to use Chinese for its encoding, all my ASCII text 
files would become binary?



I'd rather have simple rule (such as text is UTF-8 encoded) rather
than some fuzzy heuristic that is sure to fail when you don't want it to.


One rule that never fails is to let me decide what a file is because I know 
what my files contain better than anyone else!



Will


___
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 force text for all files?

[tonyp]

Hi,

I’m looking for a way to force all files (except those matching binary-glob) to 
be treated as text rather than automatically (mis-)detected as binary.

Any way to do that?

TIA___
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 force text for all files?

[tonyp]

One common (for me) example is a text file that includes maybe just one or two 
special 8-bit ASCII codes.  This causes the whole files to be stored as binary 
and makes it impossible to ‘diff’.

From: Richard Hipp 
Sent: Saturday, December 06, 2014 10:16 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to force text for all files?



On Sat, Dec 6, 2014 at 3:12 PM, to...@acm.org wrote:

  Hi,

  I’m looking for a way to force all files (except those matching binary-glob) 
to be treated as text rather than automatically (mis-)detected as binary.



Can you share with us what it is about your files that cause them to be 
misdetected as binary?


-- 

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



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

Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[tonyp]

And I have to ask: Why do you have to ask? :)  A problem is a problem 
regardless of how it became evident.

No, I don’t keep read-only files under fossil control, obviously.  Note I used 
the word ‘happens’ to be read-only.

The read-only status was set to temporarily protect this one file from being 
overwritten along with all other changed files in the repo.  So, rather than 
answer Y/N to whether to overwrite each file individually from the whole lot, I 
set the read-only flag to the one I didn’t want overwritten, and answered Yes 
to all...

From: Stephan Beal 
Sent: Thursday, November 13, 2014 5:20 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after 
failing to overwrite write-protected file

On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote:

  When opening a repo, if you select to overwrite all files, and a file to be 
updated happens to be read-only (R attrib set), the overwrite fails (it should) 
but if you then change the read-only to read-write, and try to see changes or 
try to revert the failed to update file with the repo version, nothing happens. 
 FOSSIL somehow assumes that the checkout is in a correct state, even though it 
failed to overwrite, and the repo and check-out have different copies of the 
same file.

That's apparently a bug (and thank you for the reproduction steps), but i've 
gotta ask: why on earth would have a read-only file under fossil's control (as 
opposed to having read-only generated files, which i do to keep me from 
accidentally editing the generated Makefiles instead of their input tempates)? 
Fossil doesn't store/set any attributes except +x (git doesn't support other 
attributes either (anymore), based on what i've read).


-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[tonyp]

I agree it’s not an everyday use case.  I’ve been using fossil for nearly a 
year now, and it happened to me only once, just now.  And, I’ve learned my 
lesson, so I’ll be more careful for this not to happen again.

However, this is the kind of situation that it may not bite often at all but if 
it ever bites you, it might hurt a lot as you’ll end up losing possibly the 
only copy of a file, as committing won’t include this one, and closing the repo 
won’t warn you about uncommitted changes, and you may go home happy thinking 
everything is in order... until you blissfully overwrite it (this now no longer 
read-only file) next time you open the repo with the wrong version.

From: Stephan Beal 
Sent: Thursday, November 13, 2014 7:19 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after 
failing to overwrite write-protected file

On Thu, Nov 13, 2014 at 6:11 PM, to...@acm.org wrote:

  And I have to ask: Why do you have to ask? :)  A problem is a problem 
regardless of how it became evident.

Because i'm deciding whether it's worth investing time to fix what might be a 
non-problem (or a problem outside fossil's scope) ;).

FWIW: i generally cringe when people respond to posts with why would you want 
to? and should have said why i was asking in my initial reply.

  No, I don’t keep read-only files under fossil control, obviously.  Note I 
used the word ‘happens’ to be read-only.

Fair enough.

  The read-only status was set to temporarily protect this one file from being 
overwritten along with all other changed files in the repo.  So, rather than 
answer Y/N to whether to overwrite each file individually from the whole lot, I 
set the read-only flag to the one I didn’t want overwritten, and answered Yes 
to all...

In any case, i agree it's a bug, but looking into it isn't high on my personal 
prio list because it's a really weird edge case with relatively little impact 
(as perceived by my limited world view). Could i convince you to post a ticket 
for it, including the bits from your first post, so we don't lose track of it?

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



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

[fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[tonyp]

(This was seen on a Windows 7 machine)

When opening a repo, if you select to overwrite all files, and a file to be 
updated happens to be read-only (R attrib set), the overwrite fails (it should) 
but if you then change the read-only to read-write, and try to see changes or 
try to revert the failed to update file with the repo version, nothing happens. 
 FOSSIL somehow assumes that the checkout is in a correct state, even though it 
failed to overwrite, and the repo and check-out have different copies of the 
same file.

Here’s the test batch file I ran which shows the problem:

@echo off
echo Reproduce fossil issue with read-only overwrite failure consequences
echo (where f = fossil)
f ver -v
f new sample.fossil
md xxx
dir  xxx\aaa
cd xxx
f o ..\sample.fossil
f add aaa
f com -m Initial
f close
echo Make some changes to our file
dir ../s  aaa
attrib +r aaa
echo Answer Y or A(ll)
f o ..\sample.fossil
echo Failed to update.  Let's remove the read-only status, and see...
attrib -r aaa
f cha
f rev
f com
echo Nothing shown here.  But, if we close and re-open the repo.
f close
echo Answer N
f o ..\sample.fossil
f cha
echo Obviously, there are changes!!!


--
OUTPUT
--
Reproduce fossil issue with read-only overwrite failure consequences
(where f = fossil)
This is fossil version 1.30 [b9a1beda9e] 2014-10-25 01:01:31 UTC
Compiled on Oct 25 2014 19:30:07 using msc-18.00 (32-bit)
SQLite 3.8.7 2014-10-17 11:24:17 e4ab094f8a
Schema version 2011-04-25 19:50
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.1j 15 Oct 2014)
project-id: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
server-id:  2f3a9fff39ebc03e8d9879929afa6075b8ee766f
admin-user: Tony (initial password is db3f67)
project-name: unnamed
repository:   C:/temp/xxx/..\sample.fossil
local-root:   C:/temp/xxx/
config-db:C:/Users/Tony/AppData/Local/_fossil
project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
checkins: 0
ADDED  aaa
New_Version: e2507b54298d9a57da83578667dc510861fed766
Make some changes to our file
Answer Y or A(ll)
overwrite C:/temp/xxx/aaa (a=always/y/N)? y
aaa
unable to open file C:/temp/xxx/aaa for writing
Failed to update.  Let's remove the read-only status, and see...
nothing has changed; use --allow-empty to override
Nothing shown here.  But, if we close and re-open the repo.
Answer N
overwrite C:/temp/xxx/aaa (a=always/y/N)?
WARNING: manifest checksum does not agree with disk
project-name: unnamed
repository:   C:/temp/xxx/..\sample.fossil
local-root:   C:/temp/xxx/
config-db:C:/Users/Tony/AppData/Local/_fossil
project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
checkout: e2507b54298d9a57da83578667dc510861fed766 2014-11-12 21:12:17 UTC
leaf: open
tags: trunk
comment:  Initial (user: Tony)
checkins: 1
EDITED aaa
Obviously, there are changes!!!
___
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] Possible bug: Failure to acknowledge changesafter failing to overwrite write-protected file

[tonyp]

From the F SET command I see blanks for either:


mtime-changes
...
repo-cksum

Regarding mtime, I understand the batch file test maybe too fast for the 
time to change, but the problem was noticed on a file that was many hours 
away from the repo version.


-Original Message- 
From: Kees Nuyt

Sent: Wednesday, November 12, 2014 11:35 PM
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Possible bug: Failure to acknowledge 
changesafter failing to overwrite write-protected file


[Default] On Wed, 12 Nov 2014 23:16:34 +0200, to...@acm.org
wrote:


(This was seen on a Windows 7 machine)

When opening a repo, if you select to overwrite all files, and a
file to be updated happens to be read-only (R attrib set), the
overwrite fails (it should) but if you then change the read-only
to read-write, and try to see changes or try to revert the failed
to update file with the repo version, nothing happens.  FOSSIL
somehow assumes that the checkout is in a correct state, even
though it failed to overwrite, and the repo and check-out have
different copies of the same file.


What are your settings for mtime-changes and repo-cksum ?

--
Regards, Cordialement, Groet,

Kees Nuyt

___
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] FOSSIL ALL

[tonyp]

I tried it and it works very well.  Thanks.  So, I guess I can leave all repos 
open all the time at both locations, and only do PULL/SYNC/PUSH at start/end of 
work day.
(I only worry a bit about the possibility of the USB eventually becoming full 
during a ‘push’ what consequences will it have on my repo’s integrity – a 
scenario less likely to happen on a server)

BTW, the syntax for Win7 is file://d:/path/file.fossil

Hmm, now I wonder, could this file syncing also work with FTP over the Internet 
by changing file: to ftp: (or something) as I have a private FTP server on all 
the time (you know, those NAS/storage servers)?

From: Richard Hipp 
Sent: Monday, October 27, 2014 3:44 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FOSSIL ALL



On Mon, Oct 27, 2014 at 9:30 AM, Tony Papadimitriou to...@acm.org wrote:


  I use mostly Windows, but every so often I open the repo on a Linux box (but 
I can do without Linux for now).  


Most thing we get working on Linux first, as that is the primary desktop for 
most of the Fossil developers (Jan excepted)


That said, I think the previously described system of syncing to your 
thumb-drive using the file: scheme is probably going to work best for you.  To 
recap:


(1) Run fossil all setting autosync off.

(2) Make copies of all repos onto your thumb drive.

(3) For each working check-out:

(3a) fossil remote file:/path/to/repo/on/thumb/drive


The above is a one-time setup.  Now, to transfer, just plug in your thumb drive 
and do:


 fossil all sync


Then take the thumb drive home and do fossil all sync there too (having 
previously done the same 3-step setup).


I'm not exactly sure what the syntax for the the file: URL is for the D: or 
E: filesystem (or whatever your USB stick comes up as).  And I'm away from the 
office and don't have access to a  windows machine to test it.  Some 
experimentation is in order, but once you get it working, it should just work.


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



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

Re: [fossil-users] diff --tk features and to-dos. Was: Diff against working copy

[tonyp]

Please save me the trouble of search - Do I have a Contributors Agreement for 
you in the firesafe?
 
May I suggest this great SQLite3 tool to help you (1) keep track of your 
documents, and (2) quickly search for membership without even going to the safe?

(Sorry, I couldn’t resist! )___
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] New TIMELINE with FILENAME option(WAS:FINFOsuggestion)

[tonyp]

On Sun, Oct 19, 2014 at 10:14 AM, Stefan Bellon sbel...@sbellon.de wrote:

  But why not just use some switch to indicate that the following
  argument is a file/directory rather than a branch/tag/...?


From: Stephan Beal 
 
+1: no ambiguity problem and no unconventional file prefix.

So, I guess the consensus is for an –f type flag.  Fine then.  However, I would 
expect the switch –f to appear either before or after (not only before), as it 
is a modifier to the main argument, in this case the filename, and not a 
parameterized option to the main argument (like –width num, for example, where 
the argument has to follow the option name).___
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] New TIMELINE with FILENAME option(WAS:FINFOsuggestion)

[tonyp]

On second thought, regarding these arguments (from Stephan Beal) :

 @ is conventionally used by some apps to mean include list from this file

this is exactly what we need.  Include the (timeline) list from this file 
(implying about this file) 

Plus, if we go with what some other apps do, then a lot of other options may 
have to be revised as they are sometimes used with a completely different 
meaning in other popular apps.

+1 once again for the @ prefix.

Historically speaking, whoever implements it decides ;).

Oh, good!  I should harry then to implement it first, so I can get it my way 
Seriously, the objection to a prefix comes from those who didn’t even care to 
have this feature in the first place, and who are the least likely to be using 
it quite as often.  But, I like some others, will be using it all the time.  
So, shouldn’t our vote count a little more? 
(OK, I give up, do it whichever way you like.  I guess in the end I will end up 
patching it to work my way, anyway...  It shouldn’t be hard to make a patch to 
have both ways, an –f flag or a @ prefix!)
 ___
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] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)

[tonyp]

Case sensitivity does not work for directory names, only for filenames.

-Original Message- 
From: to...@acm.org 


Last change with case sensitivity for Windows works great.

___
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] New TIMELINE with FILENAME option (WAS:FINFOsuggestion)

[tonyp]

I re-ran all use cases I had tried before, and everything seems OK.

* Case-insensitivity for Windows (OK)
* Root directory (OK)
* No duplicates (OK)

From: Richard Hipp 
Sent: Saturday, October 18, 2014 1:36 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New TIMELINE with FILENAME option 
(WAS:FINFOsuggestion)



On Sat, Oct 18, 2014 at 5:37 AM, to...@acm.org wrote:

  Case sensitivity does not work for directory names, only for filenames.


Please try again with the latest.


Are we ready to merge this enhancement into trunk?  Are there any objections to 
the new command-line timeline capability? 



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



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

Re: [fossil-users] New TIMELINE with FILENAME option(WAS:FINFOsuggestion)

[tonyp]

I don’t know if anyone has noticed already, but there is an inherent ambiguity 
between possible dirnames/filenames, and tag names or internal keywords, such 
as current  now used by the timeline command.  If there is a filename by the 
same name does the word refer to the filename, or to the keyword or tag?  In 
some cases, it can be disambiguated by checking for extra required parameters 
(e.g., BEFORE requires something more to follow).

Now, before you get overly alarmed by this, let me point out that, apparently, 
the same ambiguity already existed between tags and keywords.  If, say, the tag 
“now” existed, should “fossil tim now” refer to the time now or to the tag 
named “now”?  (From a quick test, it seems to treat it as the keyword.)

I don’t know what the most reasonable solution might be, other than to ignore 
the problem altogether.  Some suggestions:

Require a filename to be prefixed by some special character like @
For example, “fossil tim @now” would refer to file or directory “now” and not 
the time now.  It would be better that the special character be applied to the 
keywords and not the filenames but it may be too late for that if compatibility 
with previous behavior must be maintained.

Another possible solution I see would be to add the new functionality under a 
new command, which would actually use the same timeline code but without 
honoring any of the
?WHEN? ?BASELINE|DATETIME?
part.  For example, it could be called “history” or “fileline” or “trace” or 
whatever.  It would use the same timeline code but without acknowledging any of 
the timeline options.

Finally, the help screen needs updating to reflect the new changes.

From: to...@acm.org 
Sent: Saturday, October 18, 2014 8:00 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New TIMELINE with FILENAME 
option(WAS:FINFOsuggestion)

I re-ran all use cases I had tried before, and everything seems OK.

* Case-insensitivity for Windows (OK)
* Root directory (OK)
* No duplicates (OK)

From: Richard Hipp 
Sent: Saturday, October 18, 2014 1:36 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New TIMELINE with FILENAME option 
(WAS:FINFOsuggestion)



On Sat, Oct 18, 2014 at 5:37 AM, to...@acm.org wrote:

  Case sensitivity does not work for directory names, only for filenames.


Please try again with the latest.


Are we ready to merge this enhancement into trunk?  Are there any objections to 
the new command-line timeline capability? 



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



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




___
fossil-users 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] New TIMELINE with FILENAMEoption(WAS:FINFOsuggestion)

[tonyp]

I see.  That’s great news!

However, the current implementation in branch cmdline-timeline-enhancement does 
not seem to behave this way.  It make give priority to keywords over tags but 
not over filenames.  For example,

C:\temp\xxxf tim now
+++ no more data (0) +++

where an slightly older trunk version ([ee46563cbd]) shows several entries 
because it interprets now as datetime.

The experimental version interprets “now” filename, which is not found in this 
case.   But, if I add a dummy file named now in the root directory, then I get:

C:\temp\xxxf tim now
=== 2014-10-18 ===
20:01:55 [3450ec3047] *CURRENT* Added now filename (user: tonyp tags: trunk)
+++ no more data (1) +++

Thanks.

From: Richard Hipp 
Sent: Saturday, October 18, 2014 10:09 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] New TIMELINE with 
FILENAMEoption(WAS:FINFOsuggestion)



On Sat, Oct 18, 2014 at 2:21 PM, to...@acm.org wrote:

  I don’t know if anyone has noticed already, but there is an inherent 
ambiguity between possible dirnames/filenames, and tag names or internal 
keywords, such as current  now used by the timeline command.  If there is a 
filename by the same name does the word refer to the filename, or to the 
keyword or tag?  In some cases, it can be disambiguated by checking for extra 
required parameters (e.g., BEFORE requires something more to follow).

  Now, before you get overly alarmed by this, let me point out that, 
apparently, the same ambiguity already existed between tags and keywords.  If, 
say, the tag “now” existed, should “fossil tim now” refer to the time now or to 
the tag named “now”?  (From a quick test, it seems to treat it as the keyword.)

It's the keyword.  If you have a subdirectory or file named now then get a 
timeline for it using


fossil timeline ./now

In other words, add ./ to the front.


 

  I don’t know what the most reasonable solution might be, other than to ignore 
the problem altogether.  Some suggestions:

  Require a filename to be prefixed by some special character like @
  For example, “fossil tim @now” would refer to file or directory “now” and not 
the time now.  It would be better that the special character be applied to the 
keywords and not the filenames but it may be too late for that if compatibility 
with previous behavior must be maintained.

  Another possible solution I see would be to add the new functionality under a 
new command, which would actually use the same timeline code but without 
honoring any of the
  ?WHEN? ?BASELINE|DATETIME?
  part.  For example, it could be called “history” or “fileline” or “trace” or 
whatever.  It would use the same timeline code but without acknowledging any of 
the timeline options.

  Finally, the help screen needs updating to reflect the new changes.

  From: to...@acm.org 
  Sent: Saturday, October 18, 2014 8:00 PM
  To: Fossil SCM user's discussion 
  Subject: Re: [fossil-users] New TIMELINE with FILENAME 
option(WAS:FINFOsuggestion)

  I re-ran all use cases I had tried before, and everything seems OK.

  * Case-insensitivity for Windows (OK)
  * Root directory (OK)
  * No duplicates (OK)

  From: Richard Hipp 
  Sent: Saturday, October 18, 2014 1:36 PM
  To: Fossil SCM user's discussion 
  Subject: Re: [fossil-users] New TIMELINE with FILENAME option 
(WAS:FINFOsuggestion)



  On Sat, Oct 18, 2014 at 5:37 AM, to...@acm.org wrote:

Case sensitivity does not work for directory names, only for filenames.


  Please try again with the latest.


  Are we ready to merge this enhancement into trunk?  Are there any objections 
to the new command-line timeline capability? 



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

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


--
  ___
  fossil-users 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





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



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

Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)

[tonyp]

That's because 'trunk' is incorrectly interpreted as filename.

This is related to the same problem I have already reported about filenames 
having priority over internal keywords and tags, instead of the other way 
around.


I suspect it will be fixed soon.

-Original Message- 
From: Stefan Bellon


snip
Now with the recent trunk build, I get:

 $ fossil timeline trunk
 +++ no more data (0) +++
 $
snip

___
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] New TIMELINE with FILENAME option (WAS:FINFOsuggestion)

[tonyp]

I see three possibly easy solutions:

1. An SQL SELECT on the tag and keyword list decides whether to treat a word 
that has no slash as keyword/tag (exists), or filename (not exists).  If 
there is a slash it is always a filename.


2. A possibly faster executing way (without having to run SQL to check 
tags), but less user-friendly due to the required extra typing, is to 
consider a filename a word that has to either include a slash anywhere 
inside it, or be just the single/double dot special notation -- anything 
else it's considered a keyword/tag:


. (current directory)
.. (parent directory)
/ (root directory)
trunk (tag)
./trunk (file or subdirectory named 'trunk')
now (keyword)
./now (file or subdirectory named 'now')

3. Use a special prefix (like @) to denote you need to refer to a filename 
(example: @filename) instead of keyword/tag.  This is possible the easiest 
to implement as it requires a simple check of the first character of a word.


But, I'm sure someone will be able to come up with better ones.

-Original Message- 
From: to...@acm.org

Sent: Sunday, October 19, 2014 1:11 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] New TIMELINE with FILENAME option
(WAS:FINFOsuggestion)

That's because 'trunk' is incorrectly interpreted as filename.

This is related to the same problem I have already reported about filenames
having priority over internal keywords and tags, instead of the other way
around.

I suspect it will be fixed soon.

-Original Message- 
From: Stefan Bellon


snip
Now with the recent trunk build, I get:

 $ fossil timeline trunk
 +++ no more data (0) +++
 $
snip

___
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] FINFO suggestion

[tonyp]

I guess the timeline equivalent would work, too!  However, I'd be more 
interested in being able to see just the code changes (i.e., check-ins) and 
not all the 'noise' about wiki edits, tickets, tags, etc which the timeline 
gives by default (unless one uses the -t ci option).  So, I thought since 
FINFO already only deals with file edits (ignoring all the rest), this would 
be the right place to do it with less changes.  But, I don't know.


-Original Message- 
From: Martin Gagnon

Sent: Friday, October 17, 2014 4:56 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FINFO suggestion

On Fri, Oct 17, 2014 at 09:59:26AM +0200, Stephan Beal wrote:

On Fri, Oct 17, 2014 at 8:34 AM, Tony Papadimitriou to...@acm.org wrote:

Would that be too much programming effort to add?  I.e., check if
‘filename’ is a directory and in that case return FINFO for all 
associated

files.



I dream about that feature since the beginning I use fossil.

Alternatively, I think modifying timeline command/webpage to have the
capability to limit it scope to one subdirectory would be nice. Imagine
a team where one is dedicated to the documentation and only work in
doc/, when he look at the timeline to follow his work, it's hard to
track changes that was made inside doc/ directory. (especially if his
college commit a lot more than him inside src/).

snip

But with the timeline approach, it would an easy add-on I guess.

snip

___
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] FINFO suggestion

[tonyp]

I did a quick try, and it seems to work OK with only one small exception, the 
root directory itself (where _FOSSIL_ is).

There, “fossil tim .” for example (which works OK in subdirectories), shows 
nothing “+++ no more data (0) +++” when obviously there is quite a lot because 
if I give “fossil tim filename” I get the history of the given filename.

Thanks for the change.

From: Richard Hipp 
Sent: Friday, October 17, 2014 6:32 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion



On Fri, Oct 17, 2014 at 10:17 AM, to...@acm.org wrote:

  I guess the timeline equivalent would work, too!  

Please try out the change on the cmdline-timeline-enhancement branch and see if 
it works for you. 


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



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

Re: [fossil-users] FINFO suggestion

[tonyp]

One more problem I see is that it sometimes shows the same timeline entry 
multiple times in a row (same SHA1 and description)

From: to...@acm.org 
Sent: Friday, October 17, 2014 7:51 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion

I did a quick try, and it seems to work OK with only one small exception, the 
root directory itself (where _FOSSIL_ is).

There, “fossil tim .” for example (which works OK in subdirectories), shows 
nothing “+++ no more data (0) +++” when obviously there is quite a lot because 
if I give “fossil tim filename” I get the history of the given filename.

Thanks for the change.

From: Richard Hipp 
Sent: Friday, October 17, 2014 6:32 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion



On Fri, Oct 17, 2014 at 10:17 AM, to...@acm.org wrote:

  I guess the timeline equivalent would work, too!  

Please try out the change on the cmdline-timeline-enhancement branch and see if 
it works for you. 


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



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




___
fossil-users 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] FINFO suggestion

[tonyp]

An observation related to the last problem.  The identical multiple entries 
seem to match the number of files that have changed in that subdirectory.  So, 
if three files changed, the same timeline entry appears three times.

From: to...@acm.org 
Sent: Friday, October 17, 2014 8:30 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion

One more problem I see is that it sometimes shows the same timeline entry 
multiple times in a row (same SHA1 and description)

From: to...@acm.org 
Sent: Friday, October 17, 2014 7:51 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion

I did a quick try, and it seems to work OK with only one small exception, the 
root directory itself (where _FOSSIL_ is).

There, “fossil tim .” for example (which works OK in subdirectories), shows 
nothing “+++ no more data (0) +++” when obviously there is quite a lot because 
if I give “fossil tim filename” I get the history of the given filename.

Thanks for the change.

From: Richard Hipp 
Sent: Friday, October 17, 2014 6:32 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] FINFO suggestion



On Fri, Oct 17, 2014 at 10:17 AM, to...@acm.org wrote:

  I guess the timeline equivalent would work, too!  

Please try out the change on the cmdline-timeline-enhancement branch and see if 
it works for you. 


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



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




___
fossil-users 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

Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO suggestion)

[tonyp]

Seems to work much better.  I no longer get duplicates.  Thanks. (I haven't 
yet checked whether the entries I see are the correct ones, e.g., no missing 
ones, but on first inspection the timeline seems correct).


So, for now the only remaining problem I can see is the failure to show any 
changes for the repo root directory (using command: FOSSIL TIMELINE .)  If I 
notice anything else, I'll report it...


Thank you.

-Original Message- 
From: Martin Gagnon

Sent: Friday, October 17, 2014 10:24 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FINFO suggestion

On Fri, Oct 17, 2014 at 08:57:50PM +0300, to...@acm.org wrote:

An observation related to the last problem.  The identical multiple
entries seem to match the number of files that have changed in that
subdirectory.  So, if three files changed, the same timeline entry
appears three times.



Please try latest version on the cmdline-timeline-enhancement branch,
it should fix this issue.

Since I'm not a SQL expert, I'm not sure if this very simple change
doesn't break anything, but for the basic test I made, it seems to
work.

--
Martin G.
___
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] New TIMELINE with FILENAME option (WAS: FINFO suggestion)

[tonyp]

This new timeline functionality really makes a huge difference in everyday 
work!  Thank you all.


-Original Message- 
From: Martin Gagnon


On Fri, Oct 17, 2014 at 10:43:53PM +0300, to...@acm.org wrote:


So, for now the only remaining problem I can see is the failure to
show any changes for the repo root directory (using command: FOSSIL
TIMELINE .)  If I notice anything else, I'll report it...


Fixed now.

___
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] New TIMELINE with FILENAME option (WAS: FINFO suggestion)

[tonyp]

Last change with case sensitivity for Windows works great.

One note about the previous fix regarding the repo root.  It assumes (based 
on comment in source) equivalence to no filename given.  But this prints 
'noise' like tickets, wiki edits, etc.
So, I guess a simple fix is to force enable the -t ci option when a 
filename is specified in that case.


Thanks for all your work.

-Original Message- 
From: Martin Gagnon

Sent: Friday, October 17, 2014 11:45 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] New TIMELINE with FILENAME option (WAS: FINFO 
suggestion)


On Fri, Oct 17, 2014 at 10:43:53PM +0300, to...@acm.org wrote:

Seems to work much better.  I no longer get duplicates.  Thanks. (I
haven't yet checked whether the entries I see are the correct ones,
e.g., no missing ones, but on first inspection the timeline seems
correct).

So, for now the only remaining problem I can see is the failure to
show any changes for the repo root directory (using command: FOSSIL
TIMELINE .)  If I notice anything else, I'll report it...



Fixed now.

--
Martin G.
___
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] New TIMELINE with FILENAME option (WAS: FINFOsuggestion)

[tonyp]

Again, thanks for the quick fix regarding forced -t ci on filename.  Works 
perfectly.  As far as I can tell this new feature is complete!  Great work!


___
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] Ordering ticket priority/severity

[tonyp]

I suppose the simplest solution would be to rename them to start with the 
required digit.  Example:


1 Critical
2 Important

-Original Message- 
From: org.fossil-scm.fossil-us...@io7m.com

Sent: Monday, October 13, 2014 12:00 AM
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Ordering ticket priority/severity

'Lo.

Currently, if I do, in a ticket report:

 ORDER BY priority, severity

I definitely get something ordered by priority and severity, but of
course the ordering relation for both columns is lexicographical. That
is, Important  Critical because Critical appears earlier in the
alphabet.

That's pretty awful! Is there a recommended way to get a better
ordering relation without having to mutilate the ticket system too
much?

M

___
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] Is it possible to add empty folders to the repo?

[tonyp]

(BETTER YET: Is it possible to REMOVE empty folders?)

For me, there is an even more ‘annoying’ problem with the way empty directories 
are handled, but I think it is the opposite use case.

For example:

You have version X that has subdirectories a, b, and c.
And, another version Y that has only a and b (c is missing, either because c 
isn’t yet created, or because c was removed, depending on whether version X 
comes before or after version Y).

In either case, if you update from version X to version Y (using FOSSIL UPDATE 
command), the c directory is emptied but not completely removed even though 
it’s not part of the currently loaded version.  This is quite a bit annoying, 
specially when you scale this problem to many such empty subdirectories.___
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] I have two trunks?

[tonyp]

If it helps:

I tried something very simple (in this example: 
https://chiselapp.com/user/rberteig/repository/WPCLI/home), and it 
apparently fixed the problem in cloned copy at least.


I shunned the empty initial checking, rebuilt, and re-enabled the artifact 
(just in case).


The timeline shows it removed! 


___
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 use the ticket subsystem?

[tonyp]

Thanks, this is great!

One problem though!  The values I set are not pulled to my local copy.  Is that 
expected?
(Server is Fossil version [3d49f04587] 2014-01-27 17:33:44 client is fossil 
version 1.30 [ee46563cbd] 2014-08-15 12:46:27 UTC)

From: Stephan Beal 
Sent: Tuesday, September 30, 2014 6:52 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] How to use the ticket subsystem?

On Tue, Sep 30, 2014 at 1:36 PM, Tony Papadimitriou to...@acm.org wrote:

  When editing a ticket, the 'Subsystem' drop-down list is blank.

  Question: How do I enter new values, or how do I define the possible values 
from which to choose?

  Since I keep multiple applications in a single repository (because they all 
depend on common library code), I would like to use this to know to which 
application the tickets refers without taking space from the actual ticket 
description.


In Admin == Tickets == Common you'll see a TH1 script, inside of which you 
might see:


set subsystem_choices {
}

(simply add it if it's not there)

Which you should then change to, e.g.:

set subsystem_choices {
  Library_Foo
  GUI
  Library_Bar
}

(Not sure what the quoting rules are for spaces - maybe Richard or Joe can 
enlighten us both in that regard.)

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] Compilation with SSL option fails on Win7

[tonyp]

I'm afraid several changes were made that were not directly related to the 
problem I was having at all, even if they may have added greater robustness 
to the build process.
(BTW, I always did NMAKE from within the win subdirectory that contains the 
makefile.msc so that was definitely not part of my problem.)


In trying to narrow down the problem, I tried compiling openssl by itself, 
outside of fossil.

(https://www.openssl.org/source/openssl-1.0.1i.tar.gz)
I followed their README.W32 steps, i.e.:

path c:\perl\bin;%path%
(I have to do this because I don't care to have PERL's path permanently 
installed)


perl Configure VC-WIN32 --prefix=\temp
ms\do_ms.bat
nmake -f ms\ntdll.mak

and I still got that same error (about link.obj missing).

So, the problem seems to be contained entirely within the openssl library 
build process, and not within FOSSIL makefiles.


So, it has to be something in the compiler configuration.  And I think I got 
it but without knowing why, however.  It's in the vc_xp.bat that runs in 
addition to vcvarsall.bat

file when setting up the MSVC paths etc.

vc_xp.bat is needed to add compatibility for WinXP targeting in the produced 
EXE/DLLs which by default is lacking in my version of MSVC.  Without it, the 
produced EXEs will not run on XP machines.  So, I tend to use it all the 
time.


vc_cp.bat contents:

@set INCLUDE=%ProgramFiles(x86)%\Microsoft 
SDKs\Windows\7.1A\Include;%INCLUDE%

@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
@set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%
@set CL=/D_USING_V110_SDK71_;%CL%
@set LINK=/SUBSYSTEM:CONSOLE,5.01 %LINK%

From this whole thing, the problem is the final line (with either 5.01 for 
32-bit, or 5.02 for 64-bit systems).  When removed, openssl compiles 
correctly, and so does fossil with SSL support.


This extra configuration (which requires the installation of some extra SDK 
from MS) comes from Microsoft's knowledge base, and assumed correct.  It 
never caused me any problems in compiling a variety of other applications, 
including SQLite, and Fossil (but when built without SSL support.) 
Apparently, however, it creates some incompatibility with the building of 
the openssl library.


This also explains why you couldn't reproduce the problem.

Thanks for all your work.

-Original Message- 
From: Joe Mistachkin

Sent: Monday, September 29, 2014 6:39 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] Compilation with SSL option fails on Win7


Stephan Beal wrote:


Pure speculation: is it a side-effect of the missing pushd, causing it not

to

be able to (A) change dirs and (B) find the file(s) it expects in those

dirs

(because (A) failed)?



Great catch.  The MSVC makefile is designed to be used from the directory it
is
contained in.  This should now be more strongly enforced, here:

https://www.fossil-scm.org/index.html/info/86de8cbeb5

--
Joe Mistachkin

___
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] Compilation with SSL option fails on Win7

[tonyp]

Here's what I do:

(I have installed the latest perl - Strawberry Perl, and I have installed 
openssl-1.0.1i.tar.gz under the compat subdirectory)


Then (with MSVC) I do:

nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1

and after some successful work, it halts with this message:

--
C:\temp\compat\openssl-1.0.1iperl util\mkdef.pl 32 ssleay 
1ms\ssleay32.def


Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Building OpenSSL
   perl util/copy.pl .\crypto\buildinf.h tmp32\buildinf.h
Copying: ./crypto/buildinf.h to tmp32/buildinf.h
   perl util/copy.pl .\crypto\opensslconf.h 
inc32\openssl\opensslconf.h


Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
   link /nologo /subsystem:console /opt:ref /debug 
/out:out32\md4test.exe @

C:\Users\Tony\AppData\Local\Temp\nmCE0C.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 
12.0

\VC\BIN\link.EXE' : return code '0x49d'
Stop.
NMAKE : fatal error U1077: 'pushd' : return code '0x2'
Stop.
--

Any ideas what's missing (link.obj apparently but why?) or misconfigured?

TIA 


___
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] Compilation with SSL option fails on Win7

[tonyp]

Update (if it helps):

The problem appears in the latest trunk version [e061a675e6].

I also tried with an earlier version [ee46563cbd], and it worked OK.  But 
the latest trunk fails consistently, so something must have broken in 
between these two.


-Original Message- 
From: to...@acm.org

Sent: Sunday, September 28, 2014 8:44 PM
To: Fossil SCM user's discussion
Subject: [fossil-users] Compilation with SSL option fails on Win7

Here's what I do:

(I have installed the latest perl - Strawberry Perl, and I have installed
openssl-1.0.1i.tar.gz under the compat subdirectory)

Then (with MSVC) I do:

nmake -f Makefile.msc FOSSIL_ENABLE_SSL=1

and after some successful work, it halts with this message:

--
C:\temp\compat\openssl-1.0.1iperl util\mkdef.pl 32 ssleay
1ms\ssleay32.def

Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Building OpenSSL
   perl util/copy.pl .\crypto\buildinf.h tmp32\buildinf.h
Copying: ./crypto/buildinf.h to tmp32/buildinf.h
   perl util/copy.pl .\crypto\opensslconf.h
inc32\openssl\opensslconf.h

Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
   link /nologo /subsystem:console /opt:ref /debug
/out:out32\md4test.exe @
C:\Users\Tony\AppData\Local\Temp\nmCE0C.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio
12.0
\VC\BIN\link.EXE' : return code '0x49d'
Stop.
NMAKE : fatal error U1077: 'pushd' : return code '0x2'
Stop.
--

Any ideas what's missing (link.obj apparently but why?) or misconfigured?

TIA

___
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] Compilation with SSL option fails on Win7

[tonyp]

Nope!  The same exact error.

I uninstalled StraberryPerl before installing ActivePerl.

So, the problem is elsewhere.  Also, as I mentioned in the follow-up email:

The problem appears in the latest trunk version [e061a675e6].

When I tried with an earlier version [ee46563cbd], it worked OK.  Since the 
latest trunk fails consistently (regardless of Perl version used), something 
must have broken sometime in between these two check-ins.


-Original Message- 
From: Joe Mistachkin

Sent: Sunday, September 28, 2014 9:16 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] Compilation with SSL option fails on Win7


to...@acm.org wrote:


(I have installed the latest perl - Strawberry Perl, and I have installed
openssl-1.0.1i.tar.gz under the compat subdirectory)



I suspect this may have to do with the line-endings in the OpenSSL files.

Please try again with ActiveState Perl and let us know if that fixes the
issue.

The PERLDIR=C:\path\to\ActiveState\Perl\bin can be used to force the build
process to use that installed instance of Perl; however, for the Command
Prompt Window being used to compile Fossil, you will also want to make sure
that none of the Strawberry Perl binary directories are located in the PATH.

--
Joe Mistachkin

___
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] Compilation with SSL option fails on Win7

[tonyp]

I'm building on Win7 64-bit.  Tomorrow, at work, I can try again on a Win7 
32-bit, and see if that makes a difference.


Version [ee46563cbd] built without any errors, and apparently has SSL 
support (much larger file size, and an attempt to connect to an HTTPS server 
did not produce errors about missing SSL support).
So, the question is, if that older version relies on pre-built SSL 
libraries, where does it find them?  And, why can't I do the same (use these 
pre-built SSL libraries) when building the latest trunk version?


-Original Message- 
From: Joe Mistachkin

Sent: Sunday, September 28, 2014 10:44 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] Compilation with SSL option fails on Win7


to...@acm.org wrote:


When I tried with an earlier version [ee46563cbd], it worked OK.  Since

the

latest trunk fails consistently (regardless of Perl version used),

something

must have broken sometime in between these two check-ins.



That version ([ee46563cbd]) makes no attempt to automatically build OpenSSL;
therefore, it relies on the OpenSSL libraries already being built.

I'm unable to replicate this issue here locally and I just built an SSL
enabled
Fossil binary here with MSVC (yesterday).

Are you building for x86 or x64?  I suspect the current Makefile.msc will
only
work for x86 builds.  I'll look into fixing that.

--
Joe Mistachkin

___
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] gdiff/opendiff on os x: suppress unchanged files?

[tonyp]

If it's any consolation, the same problem exists under Windows with WinDiff 
(default GDIFF program).


I suppose the reason for this is the screening of which files to show is 
done by the application, and not fossil.  And, WinDiff, in my case has no 
problem showing a comparison between two equal files.
If only the actual changed files would be passed to the GDIFF app, then this 
issue wouldn't exist.  But I could be guessing wrong.


-Original Message- 
From: Dömötör Gulyás

Sent: Wednesday, September 24, 2014 8:54 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged 
files?


Thanks, fossil diff --tk works for the interim, but the diffs
provided by FileMerge/opendiff I would prefer. Isn't opendiff the
default gdiff on OS X (or did I just already have it my settings?)? If
it is, i reckon it oughta work :)

___
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] gdiff/opendiff on os x: suppress unchanged files?

[tonyp]

Here’s a very easy way to verify the problem (at least on a Win machine):

(F = FOSSIL)
(This is fossil version 1.30 [ee46563cbd] 2014-08-15 12:46:27 UTC)
1. f g --from prev any_unchanged_file_path
2. f diff --tk --from any_unchanged_file_path
[1] will show the files but without any differences.
[2] will show a popup saying “Fossil Diff – No Changes”
any_unchanged_file_path is the path/name of any file you choose that is known 
not to have changed from the previous version.___
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] gdiff/opendiff on os x:suppress unchanged files? (OOPS)

[tonyp]

Here’s a very easy way to verify the problem (at least on a Win machine):

(F = FOSSIL)
(This is fossil version 1.30 [ee46563cbd] 2014-08-15 12:46:27 UTC)
1. f g --from prev any_unchanged_file_path
2. f diff --tk –from prev any_unchanged_file_path
[1] will show the files but without any differences.
[2] will show a popup saying “Fossil Diff – No Changes”
any_unchanged_file_path is the path/name of any file you choose that is known 
not to have changed from the previous version.



___
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] gdiff/opendiff on os x: suppress unchanged files?

[tonyp]

There is a Show Identical Files option in WinDiff but changing only 
affects whether the contents of the files are shown, or a blank screen is 
shown.
The problem is still that the WinDiff application is invoked even though 
there is no difference in the files.


-Original Message- 
From: dave

Sent: Wednesday, September 24, 2014 10:14 PM
To: 'Fossil SCM user's discussion'
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged 
files?


Interestingly, this does /not/ happen for me on Windows with WinDiff.  (I
had occaision to do this just yesterday, and it only presented sequentially
the three files that had actual changes).  Don't know if version is related;
I am using the 1.29 version that came out in June.  Or maybe it's a setting
in my windiff (or can windiff settings have an opportunity to affect this
behavior).


-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf
Of to...@acm.org
Sent: Wednesday, September 24, 2014 1:02 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress
unchanged files?


If it's any consolation, the same problem exists under
Windows with WinDiff
(default GDIFF program).

I suppose the reason for this is the screening of which files
to show is
done by the application, and not fossil.  And, WinDiff, in my
case has no
problem showing a comparison between two equal files.
If only the actual changed files would be passed to the GDIFF
app, then this
issue wouldn't exist.  But I could be guessing wrong.

-Original Message- 
From: Dömötör Gulyás

Sent: Wednesday, September 24, 2014 8:54 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress
unchanged
files?

Thanks, fossil diff --tk works for the interim, but the diffs
provided by FileMerge/opendiff I would prefer. Isn't opendiff the
default gdiff on OS X (or did I just already have it my settings?)? If
it is, i reckon it oughta work :)

___
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

Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files?

[tonyp]

Wait a moment, did you specify a path/file with the GDIFF command, or was it a 
show-me-all case, i.e., no files given?

Because the latter will correctly go only through the files that have changed.

The problem appears when you specify a set of files (even a single one).  Then, 
all specified files are shown whether they have differences or not, whereas 
with the simple DIFF command nothing is shown.

-Original Message- 
From: dave 
Sent: Wednesday, September 24, 2014 10:14 PM 
To: 'Fossil SCM user's discussion' 
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files? 

Interestingly, this does /not/ happen for me on Windows with WinDiff.  (I
had occaision to do this just yesterday, and it only presented sequentially
the three files that had actual changes).  Don't know if version is related;
I am using the 1.29 version that came out in June.  Or maybe it's a setting
in my windiff (or can windiff settings have an opportunity to affect this
behavior).
___
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] gdiff/opendiff on os x: suppress unchanged files?

[tonyp]

MessageOK, but still you need to try with a file that has NOT changed.  It 
should show nothing, but you will see the file, instead.

From: dave 
Sent: Wednesday, September 24, 2014 11:17 PM
To: 'Fossil SCM user's discussion' 
Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files?

gotcha.  Yes, I think it was the 'show-me-all' case of
fossil gdiff
let me see if I can rdp into that box and try it out now

OK, still works for me.  More scoop, my checkout state:

C:\Experiments\libfossilfossil changes
EDITED include/fossil-scm/fossil-config.h
EDITED src/fsl_buffer.c
EDITED src/fsl_cli.c
EDITED src/fsl_md5.c
EDITED src/fsl_utf8.c

and doing it the 'show-me-all' way

C:\Experiments\libfossilfossil gdiff

gives me five seqential WinDiff presentations.  And doing it the 'explicit' way:

C:\Experiments\libfossilfossil gdiff include\fossil-scm\fossil-config.h

gives me one and only one WinDiff presentation.

which version of fossil are you using?  I'm on 1.29

-dave
  -Original Message-
  From: fossil-users-boun...@lists.fossil-scm.org 
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of to...@acm.org
  Sent: Wednesday, September 24, 2014 3:02 PM
  To: Fossil SCM user's discussion
  Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files?


  Wait a moment, did you specify a path/file with the GDIFF command, or was it 
a show-me-all case, i.e., no files given?

  Because the latter will correctly go only through the files that have changed.

  The problem appears when you specify a set of files (even a single one).  
Then, all specified files are shown whether they have differences or not, 
whereas with the simple DIFF command nothing is shown.

  -Original Message- 
  From: dave 
  Sent: Wednesday, September 24, 2014 10:14 PM 
  To: 'Fossil SCM user's discussion' 
  Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files? 

  Interestingly, this does /not/ happen for me on Windows with WinDiff.  (I
  had occaision to do this just yesterday, and it only presented sequentially
  the three files that had actual changes).  Don't know if version is related;
  I am using the 1.29 version that came out in June.  Or maybe it's a setting
  in my windiff (or can windiff settings have an opportunity to affect this
  behavior).




___
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] UI diff issue

[tonyp]

Hi all,
(This is fossil version 1.30 [ee46563cbd] 2014-08-15 12:46:27 UTC)
When using the UI to look at differences between versions by marking the little 
square boxes to indicate the ‘from’ and ‘to’ versions, if you mark the ‘from’ 
but need to go a different page (using newer/older) to mark the ‘to’, then as 
soon as the page changes, the ‘from’ mark is forgotten.  So, it seems 
impossible (via UI) to compare between versions that do not appear on the same 
screen at the same time.  Or, am I doing it wrong?
TIA___
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] UI diff issue

[tonyp]

Oh, I see.  Well, one possible solution I can think without knowing if it would 
be easy (or even possible) to implement:

When someone selects a ‘from’ box, the script should update the links for 
older/newer options to include the selected ‘from’ parameter. 
[Perhaps the URL (for Older/Newer) can be stored in a variable, and then that 
variable updated according to whether a ‘from’ is currently 
selected/de-selected]:

http://localhost:8080/timeline?n=20b=2014-09-19+08:21:21

upon pressing (say, Older) should become something like:

http://localhost:8080/timeline?n=20b=2014-09-19+08:21:21from=whatever-hash-value-from-has

and, if the ‘from’ parameter is present on entering the page, then a click on a 
box should make that the ‘to’ selection, rather than a new ‘from’.

Would something like this work?

From: Stephan Beal 
Sent: Sunday, September 21, 2014 2:59 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] UI diff issue

On Sun, Sep 21, 2014 at 1:53 PM, to...@acm.org wrote:

  newer/older) to mark the ‘to’, then as soon as the page changes, the ‘from’ 
mark is forgotten.  So, it seems impossible (via UI) to compare between 
versions that do not appear on the same screen at the same time.  Or, am I 
doing it wrong?

The state for the selection is stored in JavaScript, and the JS environment 
gets cleared when loading a new page. At the moment we don't have a mechanism 
for selecting (with the mouse) far away diffs, but you can achieve it by 
copying the version numbers and creating the URL manually. Alternately, you can 
use the 200 entries menu item to first expand the list of versions, and the 
checkins only entry to further weed out non-commit entries (which cannot be 
diffed against).

As far as i'm aware, nobody has pointed this limitation out before, which 
implies that doing far away diffs this way is a bit of a corner case. That 
said, if you can suggest a concrete solution for how to implement it (given our 
limitations such as, e.g., no jQuery), we're all ears.


-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] UI diff issue

[tonyp]

Correction:

upon pressing (say, Older) should become something like:

upon selecting a ‘from’ should become something like:

From: to...@acm.org 
Sent: Sunday, September 21, 2014 3:45 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] UI diff issue

Oh, I see.  Well, one possible solution I can think without knowing if it would 
be easy (or even possible) to implement:

When someone selects a ‘from’ box, the script should update the links for 
older/newer options to include the selected ‘from’ parameter. 
[Perhaps the URL (for Older/Newer) can be stored in a variable, and then that 
variable updated according to whether a ‘from’ is currently 
selected/de-selected]:

http://localhost:8080/timeline?n=20b=2014-09-19+08:21:21

upon pressing (say, Older) should become something like:

http://localhost:8080/timeline?n=20b=2014-09-19+08:21:21from=whatever-hash-value-from-has

and, if the ‘from’ parameter is present on entering the page, then a click on a 
box should make that the ‘to’ selection, rather than a new ‘from’.

Would something like this work?

From: Stephan Beal 
Sent: Sunday, September 21, 2014 2:59 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] UI diff issue

On Sun, Sep 21, 2014 at 1:53 PM, to...@acm.org wrote:

  newer/older) to mark the ‘to’, then as soon as the page changes, the ‘from’ 
mark is forgotten.  So, it seems impossible (via UI) to compare between 
versions that do not appear on the same screen at the same time.  Or, am I 
doing it wrong?

The state for the selection is stored in JavaScript, and the JS environment 
gets cleared when loading a new page. At the moment we don't have a mechanism 
for selecting (with the mouse) far away diffs, but you can achieve it by 
copying the version numbers and creating the URL manually. Alternately, you can 
use the 200 entries menu item to first expand the list of versions, and the 
checkins only entry to further weed out non-commit entries (which cannot be 
diffed against).

As far as i'm aware, nobody has pointed this limitation out before, which 
implies that doing far away diffs this way is a bit of a corner case. That 
said, if you can suggest a concrete solution for how to implement it (given our 
limitations such as, e.g., no jQuery), we're all ears.


-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



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




___
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] diff with --from --to

[tonyp]

I suppose you’re referring to this comment:

“Note that --from branch --to current and --from branch are not quite the 
same thing.  The second form (without the --to) does a diff between the branch 
and the code in the current check-out including local uncommitted changes.  
Adding the --to option does the diff from the branch to the pristine check-out 
before local changes are applied.

So adding --from current if the --from is missing might not be exactly what 
people expect.”

Well, since the option was never available before, no one expects any specific 
behavior.  The behavior can be defined now for the first time, either way 
giving preference to the current checkout with possible uncommitted changes 
(which is what I had in mind, not knowing that an explicit ‘--from current’ 
would mean without considering the uncommitted changes).

Another suggestion: It could be added in a compatible way to the “–from without 
–to” behavior so that “–to branch” without “–from current” would behave 
differently from “—from current –to branch” but in a similar way as described 
above.

So, if I understand correctly, an explicit “--from current --to branch” could 
be used to compare the committed “current”, whereas the “--to branch” without 
an explicit “--from current” would be used to compare the current check-out 
including local uncommitted changes.

To me, it simply feels redundant to type –from current, as it’s sort of implied 
when you just say –to branch.  I’ll leave it up to the majority to decide.
From: Stephan Beal 
Sent: Friday, August 15, 2014 3:37 PM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] diff with --from --to

On Thu, Aug 14, 2014 at 12:32 PM, Stephan Beal sgb...@googlemail.com wrote:

  http://fossil-scm.org/index.html/info/d5a8940431ad8716a0168081086e07521bfb8b79


  (note: in the pending-review branch, as i'd like to be certain i'm not 
breaking something here)

@Tony: based on Richard's feedback, i'm going to close that branch. If you have 
a strong argument for why usage consistency should win out here ;) feel free to 
argue your points.


-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those 
who insist on a perfect world, freedom will have to do. -- Bigby Wolf



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