Re: [fossil-users] Infinite loop on merge

[Joel Bruick]

Hi Andy,


On 9/6/2016 3:26 PM, Andy Goth wrote:
That seems to fix it. Thank you very much for the astonishingly fast 
turnaround. There may be unintended consequences since we haven't 
done much analysis yet, so I checked your change in on the 
merge-rename-lockup branch pending further testing.


On Tue, Sep 6, 2016 at 2:20 PM, Richard Hipp > wrote:


On 9/6/16, Andy Goth > wrote:
>
> The repository is private, sorry, but I should be able to help with
> debugging.
>

Just a guess:

Index: src/merge.c
==
--- src/merge.c
+++ src/merge.c
@@ -395,11 +395,11 @@
   }
   if( zPivot ){
 vAncestor = db_exists(
   "WITH RECURSIVE ancestor(id) AS ("
   "  VALUES(%d)"
-  "  UNION ALL"
+  "  UNION"
   "  SELECT pid FROM plink, ancestor"
   "   WHERE cid=ancestor.id  AND pid!=%d
AND cid!=%d)"
   "SELECT 1 FROM ancestor WHERE id=%d LIMIT 1",
   vid, nid, pid, pid
 ) ? 'p' : 'n';



This is the right fix. It ensures that each commit is only added to the 
queue by the recursive SELECT once instead of an exponential number of 
times based on how many merge commits it finds along the way, which is 
what caused your problem. I don't know why I used UNION ALL there, but 
it's definitely wrong.
___
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] PHP Composer support for Fossil

[Joel Bruick]

BohwaZ wrote:

Just to tell you that the patch has been merged and the current
Composer release allows you to use Fossil repos right now :)


This is really cool news. 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] No progress on "fossil cp"

[Joel Bruick]

j. van den hoff wrote:
On Mon, 16 May 2016 19:02:17 +0200, Warren Young  
wrote:


1. f finfo can’t trace file history back through a rename.  The web 
version of this (f ui > Files > Ancestry) does manage to report the 
rename, but it doesn’t trace history back through that link to the 
old name.  Why would I want file history to cut off just because I 
renamed it?
2. If you attempt to merge a change between branches where one of the 
changed files was renamed after the branch point, Fossil will 
*silently* drop all changes to that file.  Then it will lie to you, 
telling you the merge was successful!  If the resulting partial merge 
compiles and runs, you might not immediately notice that you didn’t 
get 100% of the feature/fix.  (This happened to me just a week or two 
ago!)


I think I also ran into both of these problems and the second one, 
obviously, is really bad (and the first one bad enough: it's presence 
heavily discourages one (at least me...) from doing otherwise 
desirable tidyups...). I do hope there is a chance to see this fixed 
in future versions (considering there are users able to recognize a 
problem but not to fix it ;-))


Not that this is much consolation to you, Warren, or anyone else that 
ever had to deal with this, but the merge issue will be fixed in the 
next release (or now if you compile your own Fossil binary):


https://www.fossil-scm.org/index.html/info/41c2220934de8cb8
___
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] Last call for "testerCleanup" branch review...

[Joel Bruick]

Joe Mistachkin wrote:

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.


I agree that it's ready and am absolutely thrilled by what I see as a 
huge improvement to the test runner. Thanks, Joe!

___
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-dev] Call for review / testing...

[Joel Bruick]

Ross Berteig wrote:

I imagine that defining TEMP is the same issue Andy has.


Yeah, I was just looking into this on a Linux VM and found the same 
thing. If TEMP isn't set, the tester script should probably check if 
/tmp exists and just use that.

___
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

[Joel Bruick]

Richard Hipp wrote:
James Moger's circular timeline nodes and colored timeline graphs are 
easily selectable skin options available to skin designers.  For a 
comparison:


http://www.fossil-scm.org/fossil/timeline?y=ci
http://www2.fossil-scm.org/fossil/timeline?y=ci


I hope you aren't too attached to this. I finally got some time to 
experiment with making it possible to style the various graph elements 
in just about any way that CSS allows. This will give skin authors a lot 
more flexibility without requiring Fossil devs to add support for each 
desired customization.


I should have gone to bed a long time ago. I'll have a branch (probably 
called graph-css) for review/fixes/improvement up by Tuesday night at 
the latest.

___
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

[Joel Bruick]

Richard Hipp wrote:
 (1)  Adjust the CSS so that the age is not all the way over on the 
right margin


Sorry I haven't been able to contribute anything in quite a while, but 
this should be fixed on trunk 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] UTF-8 and Binary Files

[Joel Bruick]

Hi David,

David Botham wrote:

Yes, I am editing in Komodo 8.5.3 on a Windows 7 workstation.

I will peek at the files in a hex editor and see what I can see...


I use Komodo on Windows 7 quite a bit and have never had this problem. 
Does Komodo recognize the file as UTF-8 in the status bar? By default, 
it uses the system encoding(CP-1252 on my computer) for new files. If 
it's showing some other encoding, change it to UTF-8 and re-save the file.


Also, if you go into the Komodo preferences, under the 
Internationalization category, the first option is Use encoding defined 
in environment: [...]. I recommend unchecking this if you haven't 
already and setting the Custom encoding option to UTF-8. This should 
help avoid problems with files you create in the future (assuming your 
problems aren't due to a bug in Fossil's invalid UTF-8 detection, of 
course).


Hope this helps in some way...
___
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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)

[Joel Bruick]

Richard Hipp wrote:
On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams n...@cryptonector.com 
mailto:n...@cryptonector.com wrote:


On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland estifo...@gmail.com
mailto:estifo...@gmail.com wrote:
 foo.txt has changes A, B, C and D.

 After each change the developer had the foresight to do a
fossil stash
 snapshot. Now the developer decides to put changes B and D into
branch b-d
 and keep changes A and C on the trunk:

Ah, foresight.  I should be blessed, but I am not, for that that's not
how I work.


I have different reasons for opposing the ability to checking 
individual lines of a file, and I'd like to get Nico's feedback:


The reason you should never do a partial check-in of a file is because 
you clearly have not tested that partial change.  And you should 
always test your code before you commit.  Especially when committing 
to trunk.


I agree with this, but Git does make testing your staged changes 
relatively easy. You can call git stash save --keep-index to stash 
only your unstaged changes, run your tests, commit, then call git stash 
pop and continue working.


With that said, I think that adding a way to stash partial changes to 
files would be enough for what most people actually need from a staging 
area (pulling out unrelated changes so they can be committed separately).
___
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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

[Joel Bruick]

Nico Williams wrote:

On Wed, Jun 4, 2014 at 9:07 AM, Stephan Bealsgb...@googlemail.com  wrote:

On Wed, Jun 4, 2014 at 12:02 AM, Nico Williamsn...@cryptonector.com
wrote:

Mercurial too had heavy-duty branches only, then they added
bookmarks that are very similar to git branches.  Since a bookmark
is just a symbolic name for a commit... this is just a new table at
best, with two columns.

Bookmarks. That's a nice idea, actually. Added to my TODO list.


It's interesting that I just sold you on the git branching model, by
using the Mercurial analog.

I don't know what that says.  To me any heavy-duty branching model is
difficult to explain, but clearly bookmarks are easy to explain, or at
least easier to explain when you start from a heavy-duty branching
model.  Regardless of what it means, it's good!  :)


I think Git is a great, powerful, and flexible tool that actually has a 
much simpler design than it initially appears. But to get to a place 
where you actually understand that design (and, thus, understand Git), 
takes about 99x more effort than 99% of the software I've ever used.


Once you get to that point, though, it's wonderful! ;)

One serious problem I have with Git's branching model, though, is that 
the branch names don't really name branches.


If I want to go back and dig through the history of an old feature-x 
branch, I get the commit that the feature-x ref is currently pointing to 
along with every other ancestor of that commit -- including every 
ancestor of the commit that feature-x branched out of and the ancestry 
of every other commit that's been merged into the feature-x branch.


Well, okay, but that's not really what reasonable human beings 
conceptualize as a branch.


This is, of course, assuming that the feature-x ref still exists. In 
Git, it is common practice for people to delete a ref (even from the 
remote repository) after the branch has been merged. To me, this really 
does amount to deleting history.


Fossil branches are actual branches, and I find this very helpful. As an 
example, I fairly often find myself wanting to look back at a specific 
commit that I remember. I obviously don't have the artifact ID 
memorized.  I only vaguely remember when it was created. While the 
commit message was clear and descriptive, I don't remember it, and 
searching for keywords that I think appear in it returns nothing. If I 
could go back in time, I would give it a tag. But heck, even Git doesn't 
include a time machine yet.


However, I do remember the branch name (and even if I don't, I can 
easily find it in the list of closed branches). Firing up fossil ui 
and going to /timeline?r=feature-x narrows it down to a handful of commits.


Anyway, there are some things that I wouldn't mind if Fossil stole from 
Git, but the branching model is not one of them.


___
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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

[Joel Bruick]

Scott Robison wrote:
On Wed, Jun 4, 2014 at 12:56 PM, Joel Bruick j...@joelface.com 
mailto:j...@joelface.com wrote:



I think Git is a great, powerful, and flexible tool that actually
has a much simpler design than it initially appears. But to get to
a place where you actually understand that design (and, thus,
understand Git), takes about 99x more effort than 99% of the
software I've ever used.

Once you get to that point, though, it's wonderful! ;)


I really want to steal this in tweet form:

To get to a place where you understand Git's design takes 99x more 
effort than 99% of software. Once you get to that point it's wonderful!


Would you mind? :)


Consider it yours.

___
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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

[Joel Bruick]

Scott Robison wrote:
On Wed, Jun 4, 2014 at 1:56 PM, Richard Hipp d...@sqlite.org 
mailto:d...@sqlite.org wrote:


On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison
sc...@casaderobison.com mailto:sc...@casaderobison.com wrote:

I really want to steal this in tweet form:

To get to a place where you understand Git's design takes 99x
more effort than 99% of software. Once you get to that point
it's wonderful!


Does that quote belong on this page:
http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki


The full original definitely belongs there:

I think Git is a great, powerful, and flexible tool that actually has 
a much simpler design than it initially appears. But to get to a place 
where you actually understand that design (and, thus, understand Git), 
takes about 99x more effort than 99% of the software I've ever used.


Once you get to that point, though, it's wonderful! ;)

Attributed to Joel Bruick. :)


I'd prefer the attribution Joel Bruick, blatantly biased Fossil 
contributor, but sure, why not?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] DRH's PGCon 2014 Keynote (with Fossil sighting!)

[Joel Bruick]

I just wanted to share Richard's PGCon 2014 keynote for anyone here that 
wasn't aware of it:


https://www.youtube.com/watch?v=ZvmMzI0X7fE

It's a great talk about the historical relationship between SQLite and 
PostgreSQL as well as a celebration of the usefulness of SQL. Richard 
goes through several specific examples of how SQLite is currently or 
could potentially be used as a superior application file format to a 
pile of files. He also throws in a dig at NoSQL databases that anyone 
who appreciates both SQL and the general concept of truth will find 
highly amusing.


Near the end of the speech (around the 32:30 mark), a certain unnamed 
SQL-based SCM makes a special appearance (spoiler alert: it's Fossil).


Thanks, Richard, and everyone else, enjoy!
___
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] working checkout does not match what would have ended up in the repository

[Joel Bruick]

Stephan Beal wrote:

Am i wrong, or did Joel's patch just correct the problem:


I hope so. The commit I backed out seems to serve no purpose besides 
messing up vfile_aggregate_checksum_disk(). Specifically, this part from 
the function's documentation:


** Newly added files that are not contained in the repository are
** omitted from the checksum if they are not in Global.aCommitFile[].

Instead, all added files were being included in the checksum, which was 
causing it to not match the repository checksum.


For what it's worth, count me among those who would like to see this 
feature remain, even if it isn't 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] FYI: doc URLs don't work with filenames that have + in their names

[Joel Bruick]

Warren Young wrote:

On May 27, 2014, at 7:55 PM, Joel Bruickj...@joelface.com  wrote:


Richard Hipp wrote:

I think that's an HTTP thing.  In a URL, spaces are encoded as +.

It's really an HTML form thing [1] that only applies to the query portion of the URL. In 
the path component, we technically should be percent-encoding spaces and leaving any 
instances of + alone, which would then allow you to reference such files 
normally.

That's a much more involved fix that offers very little value, though. Just file 
this under the more you know.”


Actually, I just came up with a use case where you want Fossil to handle + 
without URL-decoding it.

If you have foo.md containing with something like this:

...but for more on that, see [the VC++ README](README-VC++.md).

and you link to it with a doc URL, you want the generated HTML to link to 
README-VC++.md, not to “README-VC  .md”.

You can make it create the right link by replacing the + signs with %2b, but 
that makes foo.md harder to read in a text editor.  One reason to use doc URLs 
in the first place is that you want to refer to documentation files you will 
ship as part of your distributed source code, so you don’t have to have their 
content in two places.


You're right, of course. What I really meant was, Thankfully this isn't an 
important issue for me at the moment or I'd have to spend time fixing it. ;)

___
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] FYI: doc URLs don't work with filenames that have + in their names

[Joel Bruick]

Richard Hipp wrote:
I think that's an HTTP thing.  In a URL, spaces are encoded as +.  
So fossil is doing the right thing in converting + characters in the 
URL into spaces.


If the filename really does contain + symbols, then the URL should 
have %2b for each plus.  ex: 
http://localhost/doc/trunk/README-Visual-C%2b%2b.txt


It's really an HTML form thing [1] that only applies to the query 
portion of the URL. In the path component, we technically should be 
percent-encoding spaces and leaving any instances of + alone, which 
would then allow you to reference such files normally.


That's a much more involved fix that offers very little value, though. 
Just file this under the more you know.


[1] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Excluding [brackets] from a.../a links

[Joel Bruick]

Stephan Beal wrote:
On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com 
mailto:brad.har...@gmail.com wrote:


Andy, to be clear, are you suggesting:

  a) blah blah [a href=somethingcafebabe/a] blah blah blah


My comments assumed this interpretation. To my eyes that looks a tiny 
bit cleaner, but i won't argue strongly one way or the other.


This is also how I interpreted it, and also what I support doing. 
Copy/pasting artifact IDs has annoyed me before, as well.
___
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] Missing highlighted space changes in diff?

[Joel Bruick]

Jan Nijtmans wrote:

Therefore I reverted the diff-eolws branch diffFlags to what they
are in trunk now: DIFF_IGNORE_EOLWS.


Sounds good. Let's get this bug-fix-turned-feature branch into trunk! :)


Question to anyone interested:
   What should be the diffFlags used for blame/annotate
   1) DIFF_IGNORE_EOLWS   (the current behavior, ignoring all
end-of-line spacing)
   2) DIFF_IGNORE_SOLWS|DIFF_IGNORE_EOLWS (my preference, ignoring
all start-of-line and end-of-line spacing)
   3) 0:  Any difference in spacing is considered different
   4) Any other flag, to-be-implemented.


My personal preference is for (1), as EOL whitespace is practically 
never worth caring about in any way (although, as Martin pointed out, 
that isn't always the case). I'd also guess that it makes blame/annotate 
more useful for the majority of users than (3), but maybe I'm wrong on 
that. I wouldn't argue against (3) as the default, though.

___
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] Missing highlighted space changes in diff?

[Joel Bruick]

Jan Nijtmans wrote:

That said, I would prefer too the default being NOT to ignore
whitespace, that's what most other SCM's do. Except for
annotations, then it is useful to ignore all whitespacing.
Something like:
 http://fossil-scm.org/index.html/info/28b39cc516

Is that getting nearer to what's really desired?


I've made a few more changes. I'm happy with where it's at now unless 
you notice anything else. Thanks, Jan.
___
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] Missing highlighted space changes in diff?

[Joel Bruick]

Jan Nijtmans wrote:

2014-03-01 20:17 GMT+01:00 Andy Bradfordamb-fos...@bradfords.org:

I was perusing the  recent commits and noticed that the  web UI does not
highlight (in red) the actual changes here:

http://www.fossil-scm.org/index.html/info/3df526ca41

On the other hand, fossil diff --tk does actually work correctly:

fossil diff --tk --from 81162e791f  --to 3df526ca41


Well, joel started fixing this in the diff-eolws branch, and I did
some additional enhancements there. Feedback welcome!


Thanks for all the enhancements, Jan. One thing I want to argue, though, 
is that diff --tk shouldn't ignore whitespace by default. At the very 
least, it shouldn't ignore leading whitespace, which could lead to some 
unpleasant surprises for people using Fossil with a language like 
Python. And even then, we'll need to add another option for people that 
want to force display of trailing whitespace changes with diff --tk.
___
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] looking for interesting new fossil skins

[Joel Bruick]

Richard Hipp wrote:
The tree-view 
(http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/dir?ci=tiptype=tree 
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/dir?ci=tiptype=tree) 
doesn't look quite right.


That skin sets top and bottom margins on all LI elements, which the 
tree-view CSS doesn't account for. I just fixed this in trunk.

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

[fossil-users] tree-view-work branch

[Joel Bruick]

Richard, can you check the tree-view-work branch again? The only reason 
I can figure it didn't work for you is if you had an older, cached 
stylesheet that didn't get refreshed when you tried my changes. I had 
tried it (and just checked it again) in every browser I have installed 
(on both Windows and Linux) and it works fine.


Also (and this is more of a PSA for everyone, really), you may want to 
change the stylesheet link in the header of your repositories to this:


link rel=stylesheet href=$stylesheet_url type=text/css 
media=screen /


The $stylesheet_url variable changes whenever you either modify your CSS 
or update the version of Fossil you're using. I added it (along with 
$logo_image_url and $background_image_url) because I got tired of having 
to do a hard refresh to see any stylesheet changes.


Hopefully that's the cause of the problem, anyway.
___
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] Tree view and browser back button

[Joel Bruick]

Richard Hipp wrote:
Joel - thanks for trying to fix this problem.  But your patch doesn't 
work.  On ChromeVersion 31.0.1650.63 (the default on Ubuntu 13.10) 
pressing the back button returns to a collapsed tree.  And on IE10, it 
no longer expands when clicking on a directory.  (Firefox and Safari 
work in all cases that I tested, but they worked before too, so no 
change there.)


I've moved your changes into a branch until we can get them working.


Sorry, I shouldn't have committed it to trunk in the first place. I'll 
let you know when I've got it working better.
___
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] Tree view and browser back button

[Joel Bruick]

Joel Bruick wrote:
Sorry, I shouldn't have committed it to trunk in the first place. I'll 
let you know when I've got it working better.


Should be working properly now. Tested on Firefox, Chrome, and IE10/11.
___
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] tree-view of files

[Joel Bruick]

Michai Ramakers wrote:

On 6 January 2014 11:59, Michai Ramakersm.ramak...@gmail.com  wrote:

Hello,

I noticed that when clicking on 'files' in a checkin-summary (e.g.
random checkin https://www.fossil-scm.org/index.html/info/f83e0d2123),
tree-view is now displayed instead of legacy flat-dir.

No complaints here, but was this intentional? (Is 'tree' the new 'dir'..?)


actually... one obvious drawback is that due to expanding subdirs, the
actual 1st-level files/subdirs are now scattered. Is there a way to
use 'dir' as default, and 'tree'-view only when explicitly telling it
to? (TBH I haven't read all of the tree-view details yet, chances are
I missed it or am doing something wrong.)

Michai


Yeah, having everything expanded can be annoying. In the Fossil repo in 
particular, compat/zlib/ is huge. You have to scroll halfway down the 
page to get to src/, where most of the work gets done.


I'm going to add some javascript for expanding/collapsing directories. 
Then the tree-view will be practically perfect in every way.
___
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] tree-view of files

[Joel Bruick]

Joel Bruick wrote:
I'm going to add some javascript for expanding/collapsing directories. 
Then the tree-view will be practically perfect in every way.


And... done. For added convenience, you can also expand/collapse every 
subdirectory at once by clicking the root directory.
___
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] tree-view of files

[Joel Bruick]

Richard Hipp wrote:
Tnx.  That works great.  It's on the server now, after a few 
modifications, such as adding the expand query parameter which 
causes the display to start in an expanded state.


One issue I have:  There is now no longer a way to get a tree for a 
subdirectory by itself, except to enter the name= query parameter 
manually in the URL.  For example, you can no longer get to:


http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand 
http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat/tcl-8.6expand


just by clicking.  Then again, maybe I'm the only person who ever 
wants to do that so the missing capability is not important...


You can still middle/right click on the links to open the subdirectory 
pages, if you really need to scratch that itch.

___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
On Sat, Jan 4, 2014 at 11:21 PM, Joel Bruick j...@joelface.com 
mailto:j...@joelface.com wrote:


Richard Hipp wrote:


I compiled it and ran it but found the output hard to read.  I
think the problem is that the descending lines that come out of
the bottom of folders do not terminate at the list subelement of
that folder, but instead appear to keep going down into the next
sibling of the folder.


I've made some small tweaks that hopefully improve things in this
regard.


In check-in [272b684d900e23], if I look at a tree-view of the Fossil 
repo, then under compat/tcl-8.6 the line descending from the tcl-8.6 
folder should stop at its only child, generic.  But instead, it 
keeps going down past all the children of generic.


Compare against the trunk version: 
http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat 
http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat


Right. The lines descend through the entire directory's contents, 
including subdirectory files. It isn't really a design choice so much as 
it is a limitation of CSS. If there were a nice way to do traditional 
tree-view lines, I would.


I actually find it helpful, as it makes it easier to tell exactly how 
deep in the tree I am at any given point. Perhaps this is just the web 
design version of Stockholm syndrome, though.


I've made another commit that adds horizontal lines directly connecting 
each node to the vertical directory lines. Does this help at all, or 
should I just get rid of the lines entirely?
___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
On Sun, Jan 5, 2014 at 5:07 PM, Joel Bruick j...@joelface.com 
mailto:j...@joelface.com wrote:


Richard Hipp wrote:

On Sat, Jan 4, 2014 at 11:21 PM, Joel Bruick j...@joelface.com
mailto:j...@joelface.com wrote:

In check-in [272b684d900e23], if I look at a tree-view of the
Fossil repo, then under compat/tcl-8.6 the line descending from
the tcl-8.6 folder should stop at its only child, generic. 
But instead, it keeps going down past all the children of generic.


Compare against the trunk version:
http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat
http://www.fossil-scm.org/fossil/tree?ci=trunkname=compat


Right. The lines descend through the entire directory's contents,
including subdirectory files. It isn't really a design choice so
much as it is a limitation of CSS. If there were a nice way to do
traditional tree-view lines, I would.


Can you draw the lines using javascript?  Perhaps use the line-drawing 
code in the timeline as a template for how to do it?


It's certainly doable. I was just hoping to avoid doing it. I'll look 
into it.
___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
Can you draw the lines using javascript?  Perhaps use the line-drawing 
code in the timeline as a template for how to do it?


Turns out it *is* possible to do with just CSS, after all. Yippee.
___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
On Sun, Jan 5, 2014 at 10:02 PM, Joel Bruick j...@joelface.com 
mailto:j...@joelface.com wrote:


Richard Hipp wrote:

Can you draw the lines using javascript?  Perhaps use the
line-drawing code in the timeline as a template for how to do it?


Turns out it *is* possible to do with just CSS, after all. Yippee.


That's some impressive CSS.  I've merged the branch onto trunk and 
installed it on the main server.


Yeah, there are a few other ways I had tried before, but they all would 
have caused problems for people with different fonts and/or background 
colors. Impressive was the only option left.


Thanks, Richard!
___
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] CSS classes in tree-view?

[Joel Bruick]

Hi Martijn,

Martijn Coppoolse wrote:

Hi all,

I really like the new tree-view feature.
I set out to apply the same CSS tricks to differentiate files and 
directories, but it turns out that unlike the 'flat view', no CSS 
classes are included.


Would it be possible to add those to each a link?


My csstree branch uses nested lists instead of one big PRE element. This 
gives us quite a bit of flexibility in changing the look of the tree. 
The classes for dirs/files are the same as in the flat view (they're 
also placed on the LI elements). I'm guessing it'll be merged into trunk 
fairly soon.

___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
I think Joel Bruick is already working on this in a branch.  I just 
haven't gotten around to vetting and merging his changes, yet.


Richard, I'm pretty happy with the state of the csstree branch now. 
Unless I'm overlooking something, I'd say it can be merged anytime. Let 
me know if there's anything you'd like me to change.

___
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] CSS classes in tree-view?

[Joel Bruick]

Richard Hipp wrote:
On Sat, Jan 4, 2014 at 8:12 PM, Joel Bruick j...@joelface.com 
mailto:j...@joelface.com wrote:


Richard Hipp wrote:

I think Joel Bruick is already working on this in a branch.  I
just haven't gotten around to vetting and merging his changes,
yet.


Richard, I'm pretty happy with the state of the csstree branch
now. Unless I'm overlooking something, I'd say it can be merged
anytime. Let me know if there's anything you'd like me to change.


I compiled it and ran it but found the output hard to read.  I think 
the problem is that the descending lines that come out of the bottom 
of folders do not terminate at the list subelement of that folder, but 
instead appear to keep going down into the next sibling of the folder.


I've made some small tweaks that hopefully improve things in this regard.
___
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] Proposed Fossil interface enhancement.

[Joel Bruick]

Stephan Beal wrote:
On Mon, Dec 30, 2013 at 10:21 PM, Stephan Beal sgb...@googlemail.com 
mailto:sgb...@googlemail.com wrote:


Partially - i'd actually like to do something more akin to (ls
-la). A simple single-column list could (it seems) be done with CSS.


i spoke too soon - the columns are done with TDs, and CSS isn't enough 
to make those single-column.


Is there a glitch in the Matrix? ;) 
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13955.html
___
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] When modifying a file too quickly, it doesn't change

[Joel Bruick]

David Given wrote:
The big gotcha, of course, is scripts, which typically perform several 
changes on similar files in very rapid succession --- that's precisely 
how I found this myself. I find myself very uneasy about having this 
defaulting to on. I have no objection to having the option there if 
people want it, but I do think that the *default* should be the safe 
option. Particularly since Fossil prides itself on safety. With my 
particular script I spotted the error because I ended up with an empty 
checkin and commit bailed. But if that file had been part of a 
multi-file checkin set, then it would have simply been silently 
omitted from the checkin and the work lost. As a concrete example: 
after changing my script to set it to off before starting, my test 
suite now fails.


Ignoring the issue of what the default should be, I've added a --sha1sum 
option to the commit command. This way you can easily do safe commits 
in a script without having to detect/modify the mtime-changes setting 
first. You could have previously achieved the same effect by calling 
'fossil changes --sha1sum' right before your commit, but that's very 
non-obvious and relies on internal implementation details that could 
theoretically change.

___
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] Default /home and Wiki name validation?

[Joel Bruick]

Andy Bradford wrote:

Should an exception be made for a Wiki page that is the main /home page?
Or should Project names not be allowed  to be less than 2 characters? Or
is this just  an edge case that  is now documented in  the list archives
and one can either  change the name of the project, or  not use Wiki for
the main page?


The three character minimum was an arbitrary restriction that people run 
into often enough that it might as well be removed. So I have.


Join us for next week's show, when we'll discuss why wiki page names 
can't be more than 100 characters! :)

___
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] single-column file list output in web UI

[Joel Bruick]

Michai Ramakers wrote:

is there a simple way to display repo file contents in a single
column, instead of 3, in the web UI? (or at least I see 3 columns
here)


Sorry for being way late to this, but you can get the effect you 
want by adding this to your repo's CSS:


td.browser {
  display: block;
  padding: 0;
}
ul.browser {
  margin: 0;
}

Although, it would be cool to have an alternative file browser view 
similar to GitHub (for example) that would show additional metadata for 
each file.
___
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 cosmetics

[Joel Bruick]

Martijn Coppoolse wrote:

On 30-10-2013 12:15, j. van den hoff wrote:

On Wed, 30 Oct 2013 10:49:58 +0100, Richard Hipp d...@sqlite.org wrote:

== files ==

* it would be nice if directories where differentiated from files
(e.g. in
unix `ls -F' fashion) by trailing `/').


That can be done using CSS, nowadays. Since directories get a class of 
dir, you can specify the following in the CSS to get a trailing slash:


li.dira:after {
content: '/';
}

Or, if you’d rather the slash not be part of the link:

li.dir:after {
content: '/';
}

It’s also possible to change the bullet into a circle, for example:

li.dir {
   list-style-type: circle;
}

or even into a folder icon:
li.dir {
list-style-image: 
url('http://icons.iconarchive.com/icons/deleket/sleek-xp-basic/16/Folder-icon.png'); 


}

(Of course, deeplinking like this is not recommended, so it would be 
preferable to store the icon image in the repository, and refer to that).


I'm stoked that someone else uses (or at least is aware of) this. I 
added it a few months back for my own selfish purposes. And, yeah, 
replacing the standard bullets with icons is exactly what I do. You can 
even add icons based on a file's extension (files with no extension get 
the class file, *.c files get file-c, *.txt files get file-txt, etc.).


Also, an alternative to adding the icons to your repository is to embed 
them in your stylesheet as data URIs. You can use a site like this to 
convert images: http://dataurl.net/#dataurlmaker


That’s why I prefer the current CSS class-based method to hard-coded 
inclusion of the trailing slash: it enables fairly extensive 
customization. :-)


Agreed, that's why I added it! Although I suppose we can always argue on 
what the default style should be (at least until Richard says that the 
bike shed will be yellow and that's that).

___
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] window opened by `diff --tk' is editable

[Joel Bruick]

Hi j.,

I'm responsible for the new and improved Tk diff and would like to 
look into these problems. Send any screenshots and/or hate mail my way. 
I'd also like to know what OS and Tcl/Tk version you're using.


j. van den hoff wrote:
however, regarding the _new_ Tk window (as of fossil version 1.26 
[13161f39aa] 2013-08-20 11:29:01 UTC) I see the following issues:


compared to the old one, font size now is at the limit of 
comfortable readability, i.e. is too small (I could send you a screen 
shot offline, if you are interested...)
and the new central Files drop-down menu (I presume that's what it 
should be?) is broken does in fact _not_ drop down but opens a new 
small Tk window about the size of the menu button itself, containing 
the file name and three inactive close/minimize/maximize buttons. it 
disappears when clicking somewhere else in the first Tk window but not 
when releasing/clicking the menu button.


Yeah, the Files drop-down is a hack to work around problems with the 
standard Tk menu widget when you have a diff with many files. It should 
pop up a listbox just below the menu button that will allow you to 
select the file you want to jump to. It shouldn't be showing the window 
decoration/buttons, though.


so apart from the spurious edit feature I find the alt variant more 
usable (the font issue alone leads to this) and also cleaner (the 
black horizontal and vertical bars are distracting in my view and the 
bare bones `sdiff' look of the old variant was more in accord with my 
taste).


I'm not married to any of the styling. If Richard or somebody else wants 
to change it to whatever other people prefer, be my guest.


___
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] RFC: where does the /reports link belong?

[Joel Bruick]

Ron Wilson wrote:
As a developer, this makes sense to me, but  in my observations, would 
be easier a non-developer user to find it Reports on the main menu.


I don't have a problem with it being on the main menu, either -- 
especially if we eventually end up having some non-timeline-related reports.

___
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] few TODO items

[Joel Bruick]

B Harder wrote:


Sorry, on mobile and time constrained, but do private branches address 
this in any way?




I get a lot of mileage out of them, FWIW. When working on the Fossil 
codebase, I do all my experimental work (which turns out to be most of 
it...) in private branches. Then when I have something I feel relatively 
good about, I merge it into a public branch. This way I can fumble 
around with code I'm unfamiliar with or ideas I'm unsure about without 
flooding the timeline for everyone else. Richard would probably revoke 
my commit privileges if I didn't. ;)


For anyone that's interested and doesn't know about/hasn't used private 
branches, here's a simplified example workflow from when I was working 
on what eventually became the sbsreloaded branch:


fossil update trunk
# Make some changes to diff-related files and start an experimental branch.
fossil commit --private --branch diffexp
# Make some more changes, committing to this branch as I go along.
# ...
# Just had an idea for an alternative implementation.
# Go back to trunk, make a few changes, and branch again.
fossil update trunk
fossil commit --private --branch diffexp2
# Make several more commits to this branch before realizing I don't want
# to continue down this path. Go back to the original experimental branch.
fossil update diffexp
# After a bunch of commits, I finally have something I want to share.
# Merge it back into trunk and then commit it to a new public branch.
fossil update trunk
fossil merge diffexp
fossil commit --branch sbsreloaded
___
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] Side-by-side diff improvement

[Joel Bruick]

Was away from the computer all day yesterday. Thanks to everyone for the 
feedback so far. I really appreciate it.


Stephan Beal wrote:

Tab/shift-tab for me iterates through all the links on the page?


Yeah, that only works with 'fossil diff --tk'. Sorry for the confusion.
___
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] Side-by-side diff improvement

[Joel Bruick]

Lluís Batlle i Rossell wrote:

I still have to test this scrollbar proposal (I don't like much scrollbars
inside windows which already have scrollbars...), but at least it goes into a 
good direction.


Heh, I'm with you 99% of the time on excessive scrollbar hatred, but for 
this situation I think it's really the best way to do it.

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

[fossil-users] Side-by-side diff improvement

[Joel Bruick]

Hi all,

I've committed a pretty big changeto the diff 
code(http://www.fossil-scm.org/index.html/info/4081a91c84) , and I'd 
like some other people to take a look at it/test it out before it 
(maybe/hopefully) gets merged into the trunk.


The purpose of this commit is, as the commit message says, to support 
arbitrary line lengths with synced horizontal scrolling in side-by-side 
diffs. Here's an example of it in action on a test copy of the Fossil 
repo: 
http://joelface.com/fossil/fdiff?v1=98aec3c55155011bv2=d74d0c320c455abdsbs=1(you 
can click anywhere inside a diff and use the left/right arrow keys to 
scroll)


The diff --tk code also needed to be updated to support the new HTML 
output, and, well, I probably overdid it. I think it's really nice, 
though, so I hope you'll give it a try. (Tip: tab/shift-tab cycles 
through files.)


Neither the diff logic itself nor the plaintext diff output have been 
modified (if they have, it's a bug). There are also a few other minor 
changes to the web output: fixing non-compliant HTML (like div's 
inside pre's), making chunk fragment IDs not repeat on pages with 
multiple diffs, and simplifying diff error messages.


I've tested the web UI in Firefox/Chrome/IE (including IE8) and diff 
--tk on Windows 7 (Tcl 8.6) and Linux (8.4, 8.5). If there's anything I 
need to change to get this accepted into the trunk, let me know.


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] Where do you point fossil newcomers for help?

[Joel Bruick]

Hi, Stephan ,

Stephan Beal wrote:

How are you introducing new developers to using fossil for a project?

e.g. what docs (if any) do you point them to, what gotchas do you warn 
them about (are there any? ;), etc.
I haven't been in a position yet where I've had to help someone else use 
Fossil. However, I can say that when I first started using it myself, I 
found the Fossil Concepts page 
(http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki) to be 
extremely helpful. I really like the Branching, Forking, Merging, and 
Tagging page 
(http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki), 
too. Along with the Jim Schimpf's book, the quick start guide, and 
various other pages, I think Fossil is fairly well documented. Of 
course, you can never have enough good documentation.


The biggest problem I had when first learning Fossil wasn't that the 
documentation I needed didn't exist, but rather that I couldn't always 
find what I (thought I) was looking for. I think breaking up the Fossil 
doc index into categories/topics would help quite a bit.

___
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] Display of file content in the UI

[Joel Bruick]

Hi Mat,

On 5/3/2013 6:40 PM, Matthias Toggweiler wrote:

Awesome, 5 minute reaction time on this mailing list. Thanks for the
fix, Stephan.


I am likewise amazed at how quickly answers/fixes often appear on this list.


I came across this issue with HTML because I am designing a new
fossil skin, and I am aware that this little issue is irrelevant for
people who manage other types of source code.


This is a completely legitimate issue, and it had been bothering me for 
a while, too. Thanks for giving me the nudge I needed to look into 
fixing it. I've committed a fix to trunk here:


http://www.fossil-scm.org/index.html/info/63443f920b

This is actually a lot simpler of a fix than your proposals. Instead of 
inlining the HTML file directly into the artifact page, it simply loads 
it from a sandboxed iframe. This lets us maintain the current 
functionality of actually displaying the rendered HTML but prevents 
interference from scripts/styles that may be present in the file.


I've tested it in Firefox, Chrome, and IE on Windows. If anyone else 
finds any problems with it, please let me know.

___
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] current directory is not within an open checkout when viewing files in a server repository

[Joel Bruick]

Hi David,

On 4/28/2013 8:08 AM, David Evans wrote:

2013-04-22 03:50:55 d38f204d3b02815a BAD CURRENT
2013-04-22 01:33:06 7ccbf6ee6698b8f6 GOOD
Sorry, this was my screwup. I see Richard's already committed a fix to 
trunk. Thanks for reporting this.

___
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] current directory is not within an open checkout when viewing files in a server repository

[Joel Bruick]

On 4/28/2013 4:22 PM, Jan Nijtmans wrote:

After I screwed-up first ;-)


Well, fine, I guess I'll share credit with you. ;)


I committed, the 'right' solution to trunk now.


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

[fossil-users] [PATCH] Reverting renamed files

[Joel Bruick]

Last week I mentioned a bug where Fossil doesn't properly revert renamed
files. In rather quick fashion, Richard committed a fix that resolved some
of the problems associated with this. However, when I got a chance to do
some more testing I found that some issues remained. Instead of badgering
Richard or someone else to spend more time on this, I've come up with a
patch [1] that should fix all the issues I've found. I've also written a
far-from-comprehensive test file [2] that does some Fossil- and
file-system-based verifications on the results of 'fossil revert'. The
latest check-in to trunk fails four of the seven tests (the ones where a
renamed file is reverted).

To clarify exactly what this patch aims to accomplish, this is what I
believe to be the correct behavior for reverting renamed files:

Calling 'fossil revert' with either the original filename or the renamed
filename as arguments (or with no filename arguments) should have the same
result: the original file should be restored and the renamed file should be
removed. Subsequently calling 'fossil changes' and 'fossil addremove
--test' should show no entries related to either of the files involved in
the reverted rename.

I've got a CLA in the mail in case this code can be of use. If there are
any changes I need to make in order to get it incorporated into trunk, just
let me know. Thanks!

[1] http://www.joelface.com/fossil/revert-renames-fix.patch
[2] http://www.joelface.com/fossil/revert.test
___
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 rename/revert bug?

[Joel Bruick]

Hello all!

I ran into some odd behavior with running revert on a checkout in which a 
rename has just been performed. The renamed file gets deleted, but the 
original file doesn't get restored. No changes are reported by 'fossil 
changes', although the checkout is certainly not in its original state. The 
fastest way to do that is to just close and reopen the repo. Alternatively, 
you could run undo, rename the file back, and then run revert again. That 
would get more annoying if you had renamed multiple files, obviously. I also 
noticed that you can recover the original file by calling revert on the 
original filename, but then fossil appears to see it as a new file (it 
appears as ADDED in the output of 'fossil addremove --test').


This should be easy to reproduce. Just create a repo and commit a file into 
it. Then change that file's name and run 'fossil mv'. Finally, run 'fossil 
revert' and you should see the behavior I've described.


Is this the proper behavior for revert? Is there a different way I should 
handle this scenario? Is this a legitimate bug that I should file a ticket 
for (I couldn't find an existing one)? Am I a moron? The answer to one of 
these questions is certain to be yes!


Thanks for the help! 


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