Re: [fossil-users] check-in-edit branch ready?
Thus said Joe Mistachkin on Tue, 28 Jul 2015 21:02:49 -0700: It might be nice to have test coverage for the new command. Ok, this has been added: http://www.fossil-scm.org/index.html/artifact/c380f431db6dd227 Thanks for suggesting this as it was most instrumental in discovering a segfault, which is avoided with: http://www.fossil-scm.org/index.html/info/e4b5c2c2271e9949 http://www.fossil-scm.org/index.html/info/fbf3a5dd87d55c27 And a test for it here: http://www.fossil-scm.org/index.html/artifact/c380f431db6dd2278924e2e8c80e916b5c54923f?txt=1ln=386,390 All of the tests in amend.test are passing now. I think that the only coverage that is lacking is coverage for canceling all the various special tags which might exist on a checkin. Those I verified manually via ``fossil ui'', but that's because it isn't implemented in ``fossil amend.'' Should it be? This includes, for example, canceling the hidden or the closed tag on a checkin, which currently only get exercised in the UI. Any other suggestions? Thanks, Andy -- TAI64 timestamp: 400055c2f12a ___ 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] forget binary files
On 8/4/2015 6:06 AM, Stephan Beal wrote: On Tue, Aug 4, 2015 at 1:02 PM, David Mason dma...@ryerson.ca mailto:dma...@ryerson.ca wrote: Just be careful not to shun 0 length files or you won't be able to commit a 0-length file until you've cleared the shun table (because all 0-length files have the same SHA-1 id. Excellent point, though it's hard to imagine such files being either binary or holding sensitive data (except maybe in their name... hmmm interesting corner case). Files (rather, artifacts) are not shunned by name but by contents. If a file's name is the problem, shun the manifest containing the name. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] quick poll: do you generally use add/rm or mv
On 8/4/2015 12:59 AM, Stephan Beal wrote: On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig r...@cheshireeng.com mailto:r...@cheshireeng.com wrote: And then, there will be fresh set of edge cases with subtly different behavior on Windows. And for that matter, do all versions of Unix-descendents mv have the same quirks at the edges? IMHO, fossil does a remarkable job of handling rename now. I'm not sure what the ROI is for tuning the fossil mv command further... fwiw: +1 Maybe it's time to bump my old thread about a serious deficiency in renaming in combination with branching and merging. No one has replied to this thread, other than myself to report on further research. http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] quick poll: do you generally use add/rm or mv
On 8/4/2015 2:02 PM, Warren Young wrote: On Aug 3, 2015, at 4:35 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/3/2015 3:37 PM, Warren Young wrote: On Aug 3, 2015, at 12:49 PM, Andy Goth andrew.m.g...@gmail.com wrote: Any plans to bring them in sync? We had a long thread about it months ago: Pretty sure he was talking about whether or not mv and rm should touch the checkout files, not about whether their semantics should be made to match those of the like-named Unix commands. I don’t see the distinction. When I say semantics I'm explicitly *not* talking about whether or not Fossil touches the disk files. I'm talking about how Fossil interprets user intent, irrespective of whether it does its work to disk files, the list of pending changes, or a dry run/debug printout. Let's take one case where Fossil and Unix disagree about mv. mkdir -p x/dir fossil new x.fossil cd x f open ../x.fossil echo hello dir/file f addremove f mv -hard dir dir2 The last command prints: RENAME dir dir2 MOVED_FILE /home/andy/x/dir It creates an empty file called dir2 and leaves dir/file alone. It also doesn't change the change list, which still says ADDED dir/file. Unix mv would have renamed the directory from dir to dir2, i.e. made the new directory, moved all files and subdirectories into it, then removed the old directory. Fossil mv's handling of directories seems to have improved lately, but it's not really worth our time to dig up old misbehaviors. What I describe now is current as of [1d3a80474b]. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] quick poll: do you generally use add/rm or mv
On 5 August 2015 at 17:35, Andy Goth andrew.m.g...@gmail.com wrote: Let's take one case where Fossil and Unix disagree about mv. mkdir -p x/dir fossil new x.fossil cd x f open ../x.fossil echo hello dir/file f addremove f mv -hard dir dir2 The last command prints: RENAME dir dir2 MOVED_FILE /home/andy/x/dir It creates an empty file called dir2 and leaves dir/file alone. It also doesn't change the change list, which still says ADDED dir/file. This is (probably) fixed very recently in a branch: http://fossil-scm.org/index.html/timeline?r=mvHardDirFixndc=2015-07-29+18%3A44%3A10n=200 (I didn't know you could omit one hyphen from long options btw.) Michai ___ 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] fine(r) commit granularity
On 8/4/2015 3:53 PM, Warren Young wrote: It would be insufficient for apply --partial to just learn to recognize already-applied diff chunks as patch(1) does, because the chunks might have been modified before being checked in. Thus, a robust implementation of apply --partial would need to have a list of chunks you previously said “yes” to, so it can skip them the next time. Stash saves the contents of the new file, along with the baseline version. It does not save a list of diffs from the old to the new. If you manually apply a few of the diff chunks by hand (presumably after seeing them in stash show), stash pop or stash apply simply leverage the existing merge code to bring in the rest. $ f new x.fossil $ mkdir x $ cd x $ echo -e '1\n2\n3' file $ f add file $ f commit -m 1 $ echo -e '0\n1\n2\n3\n4' file $ f stash save -m s $ f stash show CHANGED file --- file +++ file @@ -1,3 +1,5 @@ +0 1 2 3 +4 $ echo -e '0\n1\n2\n3' file $ f stash pop MERGE file $ cat file 0 1 2 3 4 -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] quick poll: do you generally use add/rm or mv
On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth andrew.m.g...@gmail.com wrote: On 8/4/2015 12:59 AM, Stephan Beal wrote: On Mon, Aug 3, 2015 at 9:04 PM, Ross Berteig r...@cheshireeng.com mailto:r...@cheshireeng.com wrote: And then, there will be fresh set of edge cases with subtly different behavior on Windows. And for that matter, do all versions of Unix-descendents mv have the same quirks at the edges? IMHO, fossil does a remarkable job of handling rename now. I'm not sure what the ROI is for tuning the fossil mv command further... fwiw: +1 Maybe it's time to bump my old thread about a serious deficiency in renaming in combination with branching and merging. No one has replied to this thread, other than myself to report on further research. http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html Thanks Andy for the clear articulation of that problem. I have had people I support run into that several times. It would be really excellent to be able to tell users that they can refactor the organisation of a project using mv, rm etc. on a branch and then merge it back in. Currently it can't be done so I advise people that they should freeze development, do the refactor, then restart development. This is not something that happens all the time but when it does it is frustrating that the refactoring can't be done in parallel with development. Fixing this and making mv semantics identical to Unix would be a big win for fossil in my opinion. -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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] quick poll: do you generally use add/rm or mv
On 8/5/2015 12:34 PM, Matt Welland wrote: On Wed, Aug 5, 2015 at 8:01 AM, Andy Goth andrew.m.g...@gmail.com mailto:andrew.m.g...@gmail.com wrote: http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20758.html I have had people I support run into that several times. It would be really excellent to be able to tell users that they can refactor the organisation of a project using mv, rm etc. on a branch and then merge it back in. Currently it can't be done so I advise people that they should freeze development, do the refactor, then restart development. Have you read my follow-up emails? This part especially: Looking at the merge code, I see this comment: Rename files that have taken a rename on P-M but which keep the same name on P-V. If a file is renamed on P-V only or on both P-V and P-M then we retain the V name of the file. Thinking about this further, it's making more and more sense. The merge algorithm of working from the nearest common ancestor is built on the assumption that everything before then has already been merged. That assumption does not hold in the situation given by the second sentence of the comment quoted above. The issue is indeed a consequence of the design of the merge algorithm. Fixing it is going to take some thought. You probably should not reply to this email since it's getting far off topic. If you can, please reply to the original thread. Fixing this and making mv semantics identical to Unix would be a big win for fossil in my opinion. Agree. Thankfully, mv is going in the right direction. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ 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] quick poll: do you generally use add/rm or mv
On Wed, Aug 5, 2015 at 11:35 AM, Andy Goth andrew.m.g...@gmail.com wrote: Unix mv would have renamed the directory from dir to dir2, i.e. made the new directory, moved all files and subdirectories into it, then removed the old directory. Actually, the directory just gets rename. And if the directory is moved, Unix/Linux systems will create a new link to the directory in it's target location, then remove the original link. The time directory contents would have to be physically move is if the target location in a different file system (what Windows would call a volume or drive). The reason Fossil's mv semantics differ is because Fossil is tracking files relative to the project root. Therefore, to Fossil, dir/file.c is just the name of a file. While Unix/Linux sees the name of a directory and the name of a file in that directory. Really, Fossil is only tracking artifacts. When an artifact is a file, it's manifest artifact has a file name attribute (for that artifact) with a value like dir/file.c that means something to a Unix/Linux/other file system. To Fossil, it's just a piece of meta data being maintained in the repository. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
