[fossil-users] Merge with branch after a branch file was renamed causes mysterious behavior - possible bug?
This might be a bug: 1) Branch FooBranch and the trunk has a file named FooFile 2) FooFile gets renamed on the FooBranch to FooFileNew 3) A new file on FooBranch gets created, using the name FooFile 4) The FooBranch gets merged with the trunk 5) The merge status shows that FooFile was renamed to FooFileNew, which is correct 6) The merge status also shows that FooFile has been deleted 7) The problem is that the new FooFile on the branch never got copied to the trunk, and I was not able to find a way to get this new file from the branch via a Fossil command. I can see the new FooFile on the branch, but try as I might, I can't get it into the trunk. Is this a bug? If not, how should I get this file (and it's history) into the trunk? Thanks, Marty ___ 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] Adding Fossil to Windows Explorer context menu?
Dear Gilles, I have used the fast explorer to achieve a menu entry just beneath 7zip explorer entry. You should try the Submenu Items selection on the left side of fast explorer. But I use only the type File Folder. Best regards Bernhard -Ursprüngliche Nachricht- Von: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] Im Auftrag von Gilles Gesendet: Mittwoch, 19. Oktober 2011 15:00 An: fossil-users@lists.fossil-scm.org Betreff: Re: [fossil-users] Adding Fossil to Windows Explorer context menu? On Wed, 19 Oct 2011 09:33:15 +0200, Kohn Bernhard bernhard.k...@ait.ac.at wrote: thanks for sharing the idea using Fast Explorer. I find it very good! Actually, it's not that good because... - it requires installing Fast Explorer - it requires adding a fossil.bat just to call pause to keep the DOS box open after fossil.exe exits - fossil gdiff --from previous myfile.txt doesn't work because %1% returns the full path - the gdiff above is called for All Files, which means that this item is not displayed in the Fossil group like the other items I haven't found how to add a group + items in the context menu à la 7zip. It seems like we must write a COM DLL for this. For my personal use I have written a small .net program FossilCmd for opening a windows command console and sending fossil commands to it. Sound good. Could you upload it so we can check it out? Thank you. ___ 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] Adding Fossil to Windows Explorer context menu?
Hello Tomek, you are right, this would be the best solution. But there exist a problem with shell extension and .net. As far as I know it is not officially supported by Microsoft. First they said, that with the .net Framework 4.0 it should be available, but it is not announced (but may be I am wrong, if anybody knows better, please mail). The thing I liked with the fast explorer approach one can customize the options to the own needs, I my self only use very little commands of all the available ones, so I can configure it, to those things I really need, with very low amount of time. Best regards Bernhard Von: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] Im Auftrag von Tomek Kott Gesendet: Mittwoch, 19. Oktober 2011 17:23 An: Fossil SCM user's discussion Betreff: Re: [fossil-users] Adding Fossil to Windows Explorer context menu? For windows users, there is already an effort to get fossil extended to the explorer context menu. At the moment, the C# library for fossil commands is being written. See Ingo's SharpFossil library implementation for .NET purposes: http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil/wiki?name=SharpFossil+Library. I think that the library currently has most of the commonly used functions written, so there might be an opportunity to start coding a explorer extension using that library. Just some cents... Tomek On Wed, Oct 19, 2011 at 8:59 AM, Gilles gilles.gana...@free.frmailto:gilles.gana...@free.fr wrote: On Wed, 19 Oct 2011 09:33:15 +0200, Kohn Bernhard bernhard.k...@ait.ac.atmailto:bernhard.k...@ait.ac.at wrote: thanks for sharing the idea using Fast Explorer. I find it very good! Actually, it's not that good because... - it requires installing Fast Explorer - it requires adding a fossil.bat just to call pause to keep the DOS box open after fossil.exe exits - fossil gdiff --from previous myfile.txt doesn't work because %1% returns the full path - the gdiff above is called for All Files, which means that this item is not displayed in the Fossil group like the other items I haven't found how to add a group + items in the context menu à la 7zip. It seems like we must write a COM DLL for this. For my personal use I have written a small .net program FossilCmd for opening a windows command console and sending fossil commands to it. Sound good. Could you upload it so we can check it out? Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.orgmailto: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] Veracity
On 2011-10-20, at 01:13, Jeff Slutter j...@slutter.com wrote: A couple weeks ago I posted about the possibility of a new configuration setting called something like allow-binmerge (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict? I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved. But for that, you would need a different gmerge-command per file type. (that have a merge tool) I guess the gmerge command might be specified on command line argument and a new command line argument could be used to force the merge for binary files. This would be easier to implement than adding configuration entries for that. -- Martin ___ 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] Adding Fossil to Windows Explorer context menu?
Hello Gilles Actually, it's not that good because... - it requires installing Fast Explorer - it requires adding a fossil.bat just to call pause to keep the DOS box open after fossil.exe exits - fossil gdiff --from previous myfile.txt doesn't work because %1% returns the full path - the gdiff above is called for All Files, which means that this item is not displayed in the Fossil group like the other items I haven't found how to add a group + items in the context menu à la 7zip. It seems like we must write a COM DLL for this. For my personal use I have written a small .net program FossilCmd for opening a windows command console and sending fossil commands to it. Sound good. Could you upload it so we can check it out? I will make it available next week, when I am back in office Best regards Bernhard ___ 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] Adding Fossil to Windows Explorer context menu?
On Thu, 20 Oct 2011 12:39:43 +0200, Kohn Bernhard bernhard.k...@ait.ac.at wrote: I have used the fast explorer to achieve a menu entry just beneath 7zip explorer entry. You should try the Submenu Items selection on the left side of fast explorer. But I use only the type File Folder. That's why: It doesn't seem possible to add an item to a group that is only called when right-clicking on a file while the other items are called when right-clicking on a folder. The former will be displayed outside the Fossil group :-/ A picture being worth a thousand words... http://img543.imageshack.us/img543/8620/fossilfastexplorer.png I did some research, but the Registry doesn't seem to allow this, so coding a COM DLL seems the way to add a menu and items that can be called on either folders or files. ___ 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] Veracity
On 10/20/2011 6:46 AM, Martin Gagnon wrote: On 2011-10-20, at 01:13, Jeff Slutter j...@slutter.com wrote: A couple weeks ago I posted about the possibility of a new configuration setting called something like allow-binmerge (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict? I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved. But for that, you would need a different gmerge-command per file type. (that have a merge tool) I have a merge tool I wrote that can make the determination of what to do from the file extension. Either it does the work, spawns [and blocks] another process to do the work, or, in the case of an unmergable, asks the user to choose from either the original or the merged in version. I guess the gmerge command might be specified on command line argument and a new command line argument could be used to force the merge for binary files. This would be easier to implement than adding configuration entries for that. I had suggested a gmerge command before, but Richard pointed out that merging of files might happen outside of a [g]merge, such as when doing an update or autosyncing. ___ 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] Veracity (was: Fwd: suggestion on fossil)
Date: Thu, 20 Oct 2011 01:45:30 +0200 From: Joerg Sonnenberger jo...@britannica.bec.de To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil) Message-ID: 20111019234530.gb10...@britannica.bec.de Content-Type: text/plain; charset=us-ascii On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote: The only problem with binary files is that you cannot merge them. Even that is not necessarily true. You can't merge binary files like text files -- sure. But it doesn't mean that for a specific binary format, a merge algorithm isn't possible. Consider ODF documents for a moment. A merge program could extract the zip archive, do a *textual* merge on the XML files and zip the result up again. It works well for many use cases. Joerg Since ODF documents can be unzipped, and their XML contents are text anyway, why not make a commit program (instead of a merge program) that unzips the ODF and stores the XML in the repo ? Jos van Kesteren. ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Thursday 20 of October 2011 17:28:27 jos van kesteren wrote: Since ODF documents can be unzipped, and their XML contents are text anyway, why not make a commit program (instead of a merge program) that unzips the ODF and stores the XML in the repo ? that assumes merging /text/ of XML of ODF documents can be done in a reliable way. The format seems complex enough to make that error-prone. Same for UML files. -- dexen deVries [[[↓][→]]] http://xkcd.com/732/ ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Thu, 20 Oct 2011 17:28:27 +0200 jos van kesteren josvankeste...@gmail.com wrote: [...] Even that is not necessarily true. You can't merge binary files like text files -- sure. But it doesn't mean that for a specific binary format, a merge algorithm isn't possible. Consider ODF documents for a moment. A merge program could extract the zip archive, do a *textual* merge on the XML files and zip the result up again. It works well for many use cases. [...] Since ODF documents can be unzipped, and their XML contents are text anyway, why not make a commit program (instead of a merge program) that unzips the ODF and stores the XML in the repo ? Note that there are some problems: 1) Zipping them back is not that trivial [1] which means you have to use specialized uncommit program to properly reassemble such containers. 2) ODF container stores several files in several directories, so as soon as you unpacked it, it's not just a single file anymore, so you have to invent a way to somehow treat the files from this container as a single entity when they are stored in a DVCS. (And in some or a parallel thread here someone confirmed Fossil does only tag commits, not files.) 3) The XML files in ODF containers, while human-readable, are still autogenerated. The XML format is indeed intended to increase accessibility of the content, but innocent changes in the document from the point of view of the user who made them can result in rather interesting changes in the content files. For instance, ODT (spreadsheets), as far as I know, do not allow you to directly attach a property to a cell which would indicate that cell has red background color; instead the editor will create a special style inculding that color info (unless there's no already existing matching style) and attach it to that cell. By this I'm suggesting that diffing contents of two ODF files using only their unpacked contents could not be that straigforward to comprehend. 1. http://tanguy.ortolo.eu/blog/article24/ ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote: On Wed, Oct 19, 2011 at 6:17 PM, Michael Barrow mich...@barrow.me wrote: No -- please no locks! Concur. Locks are out-of-band for Fossil. If anybody thinks they really, really need locks, I'll be happy to offer them a referral to Veracity. I think something similar could be said about other fossil features; any feature is a plus for fossil. You also mentioned some implementation of a checklist. In a good situation, every developer in a repository will know what will be easy to merge and what not, and they should know that they have to speak with the rest of the team to edit that. And then those in the team have to remember that someone is editing that. But in a worse case, this system may fail, and some little infrastructure provided by fossil could be helpful. But, of course, first we should have a great idea to implement. :) I don't know how veracity deals with locks, but I think that they should not only be able to protect against in-branch editions, but also between branches, when there are future merges planned. With a VCS where people do a lot of feature-branches (we use fossil this way here), in-branch locks may be of little help. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Veracity
On Thu, Oct 20, 2011 at 3:46 AM, Martin Gagnon eme...@gmail.com wrote: On 2011-10-20, at 01:13, Jeff Slutter j...@slutter.com wrote: A couple weeks ago I posted about the possibility of a new configuration setting called something like allow-binmerge (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict? I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved. But for that, you would need a different gmerge-command per file type. (that have a merge tool) Others have pointed out that a smart merge tool can deal with multiple formats. But providing a way to deal with multiple different merge commands isn't that far beyond the things fossil already does. Consider a setting merge-command whose value is a list like the ignore-glob setting, except the values are regular-expression=command. Making an empty command mean use the internal merge would allow you to route all merges through it. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] More thoughts on locks
Thinking as if we had to implement locks some day... I just thought that we could have locks working not on file-paths-in-branch, but on artifacts. That would expand well to multiple branches. Then, if anyone gets the lock, and commits a new version, it could get locked automatically too, expanding the list of artifacts needing lock. Those artifacts that 'require lock' for edition could be checked out read-only. The list of locked artifacts could expand similar to the shun list, that can be told to be updated on autosync. And the list of lock owners too. Keeping the default remote as the source of locks. And apart, not requiring a locks implementation, there could be a fossil default-off option to simply check out binary files readonly (fossil seems to know what file is binary and what not). That would put a step before binary-file editions, inviting to team communication. If anyone think locks could help in their use of fossil, that chould give an opinion on this. I work either in a small team or alone, so I'm not very representative on 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] More thoughts on locks
I'm a novice Fossil user working in a small group with need to track both text and binary files. It seems to me that locks are nice to have for text files since 3 way diffs can be merged at relatively little cost. But inability to merge binary files might mean painful hand merging based on side by side comparisons for word processing documents or presentation slides, or based on repeating the edits for image files. So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. Locking artefacts provides a good way to split the chain of past and current versions. Locking should be optional to retain current behaviour for those users wanting it. How would the person doing the checkout that created the lock know this fact, as encouragement to avoid long lockout periods? How would their repository know they owned the lock? Since a commit generates a new artefact, how does the old, locked one, get unlocked? On Thu, 2011-10-20 at 19:22 +0200, Lluís Batlle i Rossell wrote: Thinking as if we had to implement locks some day... I just thought that we could have locks working not on file-paths-in-branch, but on artifacts. That would expand well to multiple branches. Then, if anyone gets the lock, and commits a new version, it could get locked automatically too, expanding the list of artifacts needing lock. Those artifacts that 'require lock' for edition could be checked out read-only. The list of locked artifacts could expand similar to the shun list, that can be told to be updated on autosync. And the list of lock owners too. Keeping the default remote as the source of locks. And apart, not requiring a locks implementation, there could be a fossil default-off option to simply check out binary files readonly (fossil seems to know what file is binary and what not). That would put a step before binary-file editions, inviting to team communication. If anyone think locks could help in their use of fossil, that chould give an opinion on this. I work either in a small team or alone, so I'm not very representative on this. ___ 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] More thoughts on locks
I just wanted to point out that Fossil has a Wiki and ticketing system built into it; these are two other methods that could be used to communicate with other team members that you would be working on something that they should not touch. I'm just sayin' Friends don't let friends use locks in their DVCSes On Thu, Oct 20, 2011 at 10:57 AM, Matt Welland estifo...@gmail.com wrote: 2011/10/20 Lluís Batlle i Rossell virik...@gmail.com Thinking as if we had to implement locks some day... I just thought that we could have locks working not on file-paths-in-branch, but on artifacts. That would expand well to multiple branches. Then, if anyone gets the lock, and commits a new version, it could get locked automatically too, expanding the list of artifacts needing lock. Actually I think you might be right on locking across branches though I'm not 100% sure. The described mechanism sounds like a really good approach. Those artifacts that 'require lock' for edition could be checked out read-only. The list of locked artifacts could expand similar to the shun list, that can be told to be updated on autosync. And the list of lock owners too. Keeping the default remote as the source of locks. And apart, not requiring a locks implementation, there could be a fossil default-off option to simply check out binary files readonly (fossil seems to know what file is binary and what not). That would put a step before binary-file editions, inviting to team communication. This is a good idea I think. It does depend on good behavior of the tools however. For example the schematic editor in use here will clearly indicate that the file was opened read-only and it will not allow edits but I've seen tools that allow you to start editing and then you can't save because the file is read-only. Of course bad tools is no reason to hesitate implementing a good idea. If anyone think locks could help in their use of fossil, that chould give an opinion on this. I work either in a small team or alone, so I'm not very representative on this. I'm 99.9% certain that if locking of some sort were available that I could expand the use of fossil to certain binary files in our team. Interestingly I ran into a scenario where I wish I had locks for my lone use of fossil. I have documentation in Lyx format and although Lyx files can sometimes be merged it isn't easy to resolve conflicts if you make lots of changes. I had forgotten that I made some substantial changes on a branch and edited my Lyx doc on the trunk. It took me over an hour to resolve the differences and get Lyx to read the merged doc. If locks were available I'd personally keep Lyx files, graphics (even svg) and other not-easy-to-merge files locked so that I don't unknowingly edit them in parallel on different computers or different branches. ___ 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 -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 01:54:19PM -0400, Chris Peachment wrote: So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. Yes, I really mean a *warning*, and not a blocker for any operation. A --force (or chmod +w) should bypass locks easily. But at least the user would have done extra work to edit the file. Locking should be optional to retain current behaviour for those users wanting it. Well, locking nothing should be an easy equivalent. How would the person doing the checkout that created the lock know this fact, as encouragement to avoid long lockout periods? long lockout periods could be fixed by the admin of the central repository, similar to the same way an artifact can be unshunned. If that does not work for the team, they better stop using locks. Any user should use the features only if they help them. How would their repository know they owned the lock? If a file needs-lock, it would be readonly. The user should issue a fossil operation (fossil edit myfile.txt); that would do the proper network communication with the default remote, asking for the lock, and if succeeded, setting write permission to the file. On commit or an unlock operation (fossil unedit myfile.txt), the readonly permission would be set again. Since a commit generates a new artefact, how does the old, locked one, get unlocked? Well, I did not think much on old artifacts. I think the lock could be kept always, unless an admin says the opposite. It would be nice to know that the artifact is not only locked, but it already derived into another locked artifact. That could be reported by fossil edit myfile.txt. Regards, Lluís. On Thu, 2011-10-20 at 19:22 +0200, Lluís Batlle i Rossell wrote: Thinking as if we had to implement locks some day... I just thought that we could have locks working not on file-paths-in-branch, but on artifacts. That would expand well to multiple branches. Then, if anyone gets the lock, and commits a new version, it could get locked automatically too, expanding the list of artifacts needing lock. Those artifacts that 'require lock' for edition could be checked out read-only. The list of locked artifacts could expand similar to the shun list, that can be told to be updated on autosync. And the list of lock owners too. Keeping the default remote as the source of locks. And apart, not requiring a locks implementation, there could be a fossil default-off option to simply check out binary files readonly (fossil seems to know what file is binary and what not). That would put a step before binary-file editions, inviting to team communication. If anyone think locks could help in their use of fossil, that chould give an opinion on this. I work either in a small team or alone, so I'm not very representative on this. ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: I'm a novice Fossil user working in a small group with need to track both text and binary files. It seems to me that locks are nice to have for text files since 3 way diffs can be merged at relatively little cost. But inability to merge binary files might mean painful hand merging based on side by side comparisons for word processing documents or presentation slides, or based on repeating the edits for image files. So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. The problem is that locking in a distributed environment is hard to do reliably. Mostly reliable could well be worse than no locking at all: you start to depend on it, and it will then naturally fail at the worst possible moment. How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. mike ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 11:05:33AM -0700, Michael Barrow wrote: I just wanted to point out that Fossil has a Wiki and ticketing system built into it; these are two other methods that could be used to communicate with other team members that you would be working on something that they should not touch. I'm just sayin' That's a fallback that some teams may agree. If we have users that would better use locks instead of common edit of a wiki page... maybe we can provide a nicer solution to them. Friends don't let friends use locks in their DVCSes I've always meant informative locks, always bypassable... I think you may be thinking of enforced locks, forbidding commits or something simliar. I would not like 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] More thoughts on locks
This is my favorite approach so far- simple, straightforward, and no complications related to offline commits or someone forgetting to remove a lock. On Thu, Oct 20, 2011 at 2:07 PM, Mike Meyer m...@mired.org wrote: On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.comwrote: I'm a novice Fossil user working in a small group with need to track both text and binary files. It seems to me that locks are nice to have for text files since 3 way diffs can be merged at relatively little cost. But inability to merge binary files might mean painful hand merging based on side by side comparisons for word processing documents or presentation slides, or based on repeating the edits for image files. So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. The problem is that locking in a distributed environment is hard to do reliably. Mostly reliable could well be worse than no locking at all: you start to depend on it, and it will then naturally fail at the worst possible moment. How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. mike ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: The problem is that locking in a distributed environment is hard to do reliably. Mostly reliable could well be worse than no locking at all: you start to depend on it, and it will then naturally fail at the worst possible moment. I think there is some better-than-nothing approach here. I saw that veracity has locks only in-branch, that for me means quite useless locks. Can't we do something better? :) How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. It looks very nice, but that should be able to be set on past checkins too, the same way you edit checkins to change tags. Otherwise, when created sounds very limiting. We don't have anything like file tags, other than the executable bit. And changing this detail may involve a change in the manifests some new artifact types. I think that something that worked as propagated-tags, but could set files readonly, would be great. That would help accross branches, and also allow avoid locking files in subgraphs. Would fossil stand some dozens of propagated tags with long names? of the kind readonly:PATH. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell virik...@gmail.com On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. It looks very nice, but that should be able to be set on past checkins too, the same way you edit checkins to change tags. Otherwise, when created sounds very limiting. Two issues. One is that it really belongs on files, not checkins. The other is that you have to figure out what to do about files derived from that one when you set the flag retroactively. We don't have anything like file tags, other than the executable bit. And changing this detail may involve a change in the manifests some new artifact types. I think that something that worked as propagated-tags, but could set files readonly, would be great. That would help accross branches, and also allow avoid locking files in subgraphs. Would fossil stand some dozens of propagated tags with long names? of the kind readonly:PATH. To bad easy to describe doesn't imply easy to implement. Having a real file properties solution would make this easy. Hmm - maybe the readonly-glob setting is enough? If it's not set, you get the current behavior. Otherwise, you check it when you pull files out of the repository (to set them read-only) or commit (unless -force is on). That also fixes the question of retroactively setting the flag. But it might be to expensive. mike ___ 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] More thoughts on locks
On Thu, Oct 20, 2011 at 11:31:01AM -0700, Mike Meyer wrote: 2011/10/20 Lluís Batlle i Rossell virik...@gmail.com On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment ch...@ononbb.com wrote: How about an having a way to flag files - when created - as read-only or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a -force to commit. A new readonly-glob setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. It looks very nice, but that should be able to be set on past checkins too, the same way you edit checkins to change tags. Otherwise, when created sounds very limiting. Two issues. One is that it really belongs on files, not checkins. The other is that you have to figure out what to do about files derived from that one when you set the flag retroactively. I'm still not sure on what would I prefer. I still have 'artifacts' in mind. Hmm - maybe the readonly-glob setting is enough? If it's not set, you get the current behavior. Otherwise, you check it when you pull files out of the repository (to set them read-only) or commit (unless -force is on). That also fixes the question of retroactively setting the flag. But it might be to expensive. I think it's becoming more and more a quick hack. :) Listing some features that people may expect for needs-lock files: 1. Avoid editing what someone already edited in another checkin, and can be merged with the branch where you plan the edit. 2. Avoid editing what another is already editing in the working dir, and can be merged with the branch where you plan the edit. For the case 2, team communication can be ideal. But for case 1, also memory plays a role, so team communication may not be the perfect solution. :) I'd expect an optional locking system to provide an alert for both cases. But maybe it is expect too much. But in five minutes I may think different. :) Regards, Lluís ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Veracity
On Thu, Oct 20, 2011 at 10:07 AM, Mike Meyer m...@mired.org wrote: On Thu, Oct 20, 2011 at 3:46 AM, Martin Gagnon eme...@gmail.com wrote: On 2011-10-20, at 01:13, Jeff Slutter j...@slutter.com wrote: A couple weeks ago I posted about the possibility of a new configuration setting called something like allow-binmerge (default off). If it is enabled, and there is a gmerge-command set, could Fossil call the gmerge-command to resolve a binary merge conflict? I would like to be able to handle merging some [proprietary] binary files with my own merge tool, but currently Fossil will refuse to call to gmerge-command when a binary file is involved. But for that, you would need a different gmerge-command per file type. (that have a merge tool) Others have pointed out that a smart merge tool can deal with multiple formats. But providing a way to deal with multiple different merge commands isn't that far beyond the things fossil already does. Consider a setting merge-command whose value is a list like the ignore-glob setting, except the values are regular-expression=command. Making an empty command mean use the internal merge would allow you to route all merges through it. My $0.02 on this subject: It may be possible to build this into fossil but it is so easy to do outside of fossil I think the added complexity just isn't justified by the limited benefit. Simply write a script that uses file on Linux or looks at the extension on Windows and chooses the merge tool accordingly and you are done. Publish the script on the fossil wiki somewhere to make it easy for the next person with this problem. Dealing with binary files is common but having specialized merge tools (that actually work worth a darn) is very rare. So we can help those with this problem by providing a simple helper script without cluttering up the settings page any more than necessary. file thumbnail thumbnail: PNG image data, 128 x 128, 8-bit/color RGBA, non-interlaced Then again maybe I'm just behind the times and tools to facilitate binary merge are now reliable and common. ___ 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] Adding Fossil to Windows Explorer context menu?
On Thu, 20 Oct 2011 15:56:43 +0200, Kohn Bernhard bernhard.k...@ait.ac.at wrote: it works. You just have to add a new submenu item with the same name but different File Type. To this submen you can add a item. http://imageshack.us/photo/my-images/830/fastexplorerfos.png Thanks much for the tip :-) I'll look around how to have the batch file remove the drive letter + replace backslashes with frontslashes: Parameters=gdiff --from previous %1 C:\My Projects\fossil.exe gdiff --from previous C:\My Projects\Form1.vb C:\fossil.exe: fossil.exe: unknown command: gdiff --from previous C:\My Projects\Form1.vb fossil.exe: use help for more information ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Creating new branch/repository problems
Hello all! I had a Fossil server set up but needed to migrate it to a new server due to its closure. The normal clone functionality was used to pull over everything and from what I can tell it's all working properly. My problems right now is that I have several uses that need to be submitting their own code that we need to keep separate from each other. I've tried to create a new branch directly and to commit new changes and specifying a new branch, but both methods fail. I'm not sure if what I need is to create a new branch of the existing repository, or a new repository altogether. I start the server by: ./fossil server groupcomm.fossil I've tried: ./fossil branch new spread groupcomm ./fossil branch new spread fossil ./fossil branch new groupcomm.fossil ./fossil commit --branch spread ./fossil commit --branch spread groupcomm.fossil No matter what command I try, the error message is always the same: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil I'm at a loss on how to set up multiple code repositories or branches here. There is no reference I can find anywhere to /home/drh (by reading this mailing list a bit, I gather drh is a real person here) nor can I figure out how to change it. Any help on how to make a new branch or new repository would be wonderful! Thanks :) Jared ___ 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] Creating new branch/repository problems
Hi, You may start with this page: http://fossil-scm.org/index.html/doc/trunk/www/faq.wiki#q3 I think the problem is that you are trying to create branch outside of an open checkout. Others may correct me if I am wrong. Regards, AlexS On Thu, Oct 20, 2011 at 8:01 PM, Jared Harder jared.har...@gmail.comwrote: Hello all! I had a Fossil server set up but needed to migrate it to a new server due to its closure. The normal clone functionality was used to pull over everything and from what I can tell it's all working properly. My problems right now is that I have several uses that need to be submitting their own code that we need to keep separate from each other. I've tried to create a new branch directly and to commit new changes and specifying a new branch, but both methods fail. I'm not sure if what I need is to create a new branch of the existing repository, or a new repository altogether. I start the server by: ./fossil server groupcomm.fossil I've tried: ./fossil branch new spread groupcomm ./fossil branch new spread fossil ./fossil branch new groupcomm.fossil ./fossil commit --branch spread ./fossil commit --branch spread groupcomm.fossil No matter what command I try, the error message is always the same: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil I'm at a loss on how to set up multiple code repositories or branches here. There is no reference I can find anywhere to /home/drh (by reading this mailing list a bit, I gather drh is a real person here) nor can I figure out how to change it. Any help on how to make a new branch or new repository would be wonderful! Thanks :) Jared ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- AlexS ___ 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] Creating new branch/repository problems
On Thu, Oct 20, 2011 at 05:01:50PM -0700, Jared Harder wrote: Hello all! I had a Fossil server set up but needed to migrate it to a new server due to its closure. The normal clone functionality was used to pull over everything and from what I can tell it's all working properly. My problems right now is that I have several uses that need to be submitting their own code that we need to keep separate from each other. I've tried to create a new branch directly and to commit new changes and specifying a new branch, but both methods fail. I'm not sure if what I need is to create a new branch of the existing repository, or a new repository altogether. I start the server by: ./fossil server groupcomm.fossil I've tried: ./fossil branch new spread groupcomm ./fossil branch new spread fossil ./fossil branch new groupcomm.fossil ./fossil commit --branch spread ./fossil commit --branch spread groupcomm.fossil No matter what command I try, the error message is always the same: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil I'm at a loss on how to set up multiple code repositories or branches here. There is no reference I can find anywhere to /home/drh (by reading this mailing list a bit, I gather drh is a real person here) nor can I figure out how to change it. Any help on how to make a new branch or new repository would be wonderful! Thanks :) Jared fossil server command is only needed to start server for web access to your repo. To execute CLI command on a repository, you need open a checkout or most of command take argument: -R reponame.fossil If you type: fossil help branchyou can read: Run various subcommands to manage branches of the _open_ repository or of the repository identified by the -R or --repository option. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell virik...@gmail.com: On Thu, Oct 20, 2011 at 11:31:01AM -0700, Mike Meyer wrote: Hmm - maybe the readonly-glob setting is enough? If it's not set, you get the current behavior. Otherwise, you check it when you pull files out of the repository (to set them read-only) or commit (unless -force is on). That also fixes the question of retroactively setting the flag. But it might be to expensive. I think it's becoming more and more a quick hack. :) Richard has already said No to locks in Fossil, so a Read Only mechanism of some kind would be the only option. I think that a readonly-glob setting should be sufficient. ___ 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] Creating new branch/repository problems
I tried this command: ./fossil branch -R groupcomm.fossil new spread groupcomm.fossil I got this response: ./fossil: unable to locate check-in off of which to branch I then tried to make sure that the groupcomm.fossil repository was the one that was open by doing ./fossil open groupcomm.fossil and I get the same original error message: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil It seems to me there is some misconfiguration with Fossil where it's referencing a directory that simply doesn't exist and it isn't looking where I've installed it to. Thanks for you replies so far! Jared fossil server command is only needed to start server for web access to your repo. To execute CLI command on a repository, you need open a checkout or most of command take argument: -R reponame.fossil If you type: fossil help branchyou can read: Run various subcommands to manage branches of the _open_ repository or of the repository identified by the -R or --repository option. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Creating new branch/repository problems
Lets go though it step by step to ensure we aren't making wrong assumptions about what you are doing. I'm not trying to be condescending, I know you probably already know all this but from the error message it is very unclear what is going on. It looks to me like you are on Linux, is that correct? After you type: fossil server groupcomm.fossil Did you get a message similar to Listening for HTTP requests on TCP port 8081 If not then your port will be 8080, if so then get the port number from the line. Now create a checkout and open the fossil. Yes, I know this is redundant, you already have a copy of the fossil but this will help clear up what is working and what is not: mkdir groupcomm cd groupcomm # use the correct port number for the next command fossil clone http://localhost:8080 mycopy.fossil fossil open mycopy.fossil You should now be in a directory with all your files. There are two ways to create a branch. Lets do it the easiest way. Edit any file (a README is good) and add a harmless trivial change such as a blank line. Now check it in on a new branch: fossil ci --branch spread -m Creating new branch spread Now check things out with the ui: fossil ui Let me know if any of the above either doesn't make sense or doesn't work. Good luck! Matt -=- On Thu, Oct 20, 2011 at 8:40 PM, Jared Harder jared.har...@gmail.comwrote: I tried this command: ./fossil branch -R groupcomm.fossil new spread groupcomm.fossil I got this response: ./fossil: unable to locate check-in off of which to branch I then tried to make sure that the groupcomm.fossil repository was the one that was open by doing ./fossil open groupcomm.fossil and I get the same original error message: ./fossil: repository does not exist or is in an unreadable directory: /home/drh/sqlite/fossil.fossil It seems to me there is some misconfiguration with Fossil where it's referencing a directory that simply doesn't exist and it isn't looking where I've installed it to. Thanks for you replies so far! Jared fossil server command is only needed to start server for web access to your repo. To execute CLI command on a repository, you need open a checkout or most of command take argument: -R reponame.fossil If you type: fossil help branchyou can read: Run various subcommands to manage branches of the _open_ repository or of the repository identified by the -R or --repository option. -- 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
