Re: [fossil-users] Adding Fossil to Windows Explorer context menu?
Hi Gilles, thanks for sharing the idea using Fast Explorer. I find it very good! For my personal use I have written a small .net program FossilCmd for opening a windows command console and sending fossil commands to it. The windows command console remains open until I close it directly. If there is already an open windows command console for this particular working directory, the command is send to this window, so there will no cluttering of serval open windows command consoles, only one per working directory (this is achieved by searching the _FOSSIL_ file in the parent directories). With the fast explorer I build an explorer menu (only for directories) and call the program (e.g. FossilCmd changes %1, where %1 is the directory I selected in explorer). This is pretty nice working (just used it for one day). If this is of any use for others, I can make this public available. 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
[fossil-users] Fwd: suggestion on fossil
-- Forwarded message -- From: Yujianbin yujian...@huawei.com Date: 2011/10/18 Subject: suggestion on fossil To: d...@hwaci.com d...@hwaci.com Hi, D. Richard Hipp, ** ** I have two suggestion on fossil: (1) support LDAP. It is a essential function for a large enterprise to manage users login and authentication. (2) support lock command, http://veracity-scm.org has this command. ** ** -- Justin Yu 俞健斌 华为技术有限公司 Huawei Technologies Co., Ltd. **[image: Company_logo]** Mobile: +86-13316882199 Email: yujian...@huawei.com 地址：深圳市龙岗区坂田华为基地 邮编：518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China http://www.huawei.com -- 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ** ** -- D. Richard Hipp d...@sqlite.org attachment: image001.jpg___ 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] Fwd: suggestion on fossil
On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote: I have two suggestion on fossil: (1) support LDAP. It is a essential function for a large enterprise to manage users login and authentication. (2) support lock command, http://veracity-scm.org has this command. My $0.02: both seem to be pretty valid points... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Veracity (was: Fwd: suggestion on fossil)
On Wed, Oct 19, 2011 at 08:18:01AM -0400, Richard Hipp wrote: -- Forwarded message -- From: Yujianbin yujian...@huawei.com (2) support lock command, http://veracity-scm.org has this command. As Yujianbin mentions veracity... I saw some videos about veracity. From the web page, the author seems quite inspired by fossil, but on the presentation about veracity, he did not mention fossil at all. http://www.ericsink.com/entries/oscon_2011_video.html I saw that as a not fair presentation, on that regard. In any case, I wanted to try veracity, and for example it still lacks 'annotate', which for me is a basic command to have. Not that I like much its 'vv log' result either. The author also clearly said that veracity 'is not community software', so he is not going to accept regular contributions as his company develops the product, but he may accept patches. Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. 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 (was: Fwd: suggestion on fossil)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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
And furthermore, how exactly do locks work in a distributed SCM context? (that was my 2 NIS) On 10/19/2011 02:50 PM, Stephan Beal wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990'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] Fwd: suggestion on fossil
On Wednesday 19 of October 2011 14:35:54 Remigiusz Modrzejewski wrote: On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote: I have two suggestion on fossil: (1) support LDAP. It is a essential function for a large enterprise to manage users login and authentication. (2) support lock command, http://veracity-scm.org has this command. My $0.02: both seem to be pretty valid points... My EUR 0.02: locking creates surprising roadblock once the team grows larger (say, 16 developers, or 8 when distributed geographically). At prev workplace, locks placed carelessly by colleauges from remote offices caused us to miss some deadlines. Of course, it was possible to work 'em around, but it took good understaing of VCS left some mess in revision history. Why does Veracity tout explicit support for file renames? From what I've seen in Git, the implicit rename model is much more robust -- it does not depend on human factor -- on remembering to issue the right command when moving files around. -- 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
On Wed, Oct 19, 2011 at 02:52:41PM +0200, Ron Aaron wrote: And furthermore, how exactly do locks work in a distributed SCM context? (that was my 2 NIS) http://veracity-scm.com/qa/questions/102/why-would-you-design-a-dvcs-in-2011-that-supports-file-locks-dvcs-are-meant-to-make-it-needless-to-worry-about-that I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. On 10/19/2011 02:50 PM, Stephan Beal wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. ___ 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] Veracity
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. So the master plan is to create an SCM for the sole purpose of selling books about the SCM (whose sole purpose is to sell a book about...)? ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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
Ah, thank you. Now I understand. And it looks to me like a big headache waiting to happen. Relying on people following intentions of the software is not very robust. On 10/19/2011 02:55 PM, Lluís Batlle i Rossell wrote: On Wed, Oct 19, 2011 at 02:52:41PM +0200, Ron Aaron wrote: And furthermore, how exactly do locks work in a distributed SCM context? (that was my 2 NIS) http://veracity-scm.com/qa/questions/102/why-would-you-design-a-dvcs-in-2011-that-supports-file-locks-dvcs-are-meant-to-make-it-needless-to-worry-about-that I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. On 10/19/2011 02:50 PM, Stephan Beal wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. ___ 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] 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
Re: [fossil-users] Veracity
IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. Tell that to the gaming companies. They use version control, and their repositories contain large numbers of very large binary files (images). The absence of locks in the DVCS world is the main reason they can't really consider getting off Perforce. The ONLY reason Veracity has locks is for this use case. -- E On 10/19/11 7:50 AM, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com mailto:virik...@gmail.com Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Veracity
Er, no. The book is free. I mean actually, er, free. In both electronic and paper forms. You can get the book in HTML, PDF or EPUB here: http://www.ericsink.com/vcbe/ The paper version is 288 pages in full color. We've shipped out over 13,000 copies, including free postage, to people all over the world. -- E On 10/19/11 7:56 AM, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com mailto:virik...@gmail.com I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. So the master plan is to create an SCM for the sole purpose of selling books about the SCM (whose sole purpose is to sell a book about...)? ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Veracity (was: Fwd: suggestion on fossil)
On Wed, 19 Oct 2011 14:50:26 +0200 Stephan Beal sgb...@googlemail.com wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. Just for fun: a lock sitting in FVWM CVS repository since 2008: http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15603.html -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 Wed, Oct 19, 2011 at 08:26:23AM -0500, Eric Sink wrote: You can get the book in HTML, PDF or EPUB here: http://www.ericsink.com/vcbe/ I was sure you were in this list ;) Thank you for the link! On 10/19/11 7:56 AM, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com mailto:virik...@gmail.com I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. So the master plan is to create an SCM for the sole purpose of selling books about the SCM (whose sole purpose is to sell a book about...)? ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Veracity
On Wed, 19 Oct 2011 14:56:47 +0200 Stephan Beal sgb...@googlemail.com wrote: So the master plan is to create an SCM for the sole purpose of selling books about the SCM (whose sole purpose is to sell a book about...)? Actually, Eric gave away this book ;-) -- Dmitry Chestnykh http://www.codingrobots.com ___ 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 Wed, Oct 19, 2011 at 08:21:55AM -0500, Eric Sink wrote: IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. Tell that to the gaming companies. They use version control, and their repositories contain large numbers of very large binary files (images). The absence of locks in the DVCS world is the main reason they can't really consider getting off Perforce. The ONLY reason Veracity has locks is for this use case. People use DVCS not only in the scenarios of lost-connection-to-a-central-server. Here, most of the time, we have a connection to it. fossil autosync is also related to that. Having locks helps a lot managing binary files in a team, I'm sure of that. And having DVCS implementing them so they work well in the connected-to-the-server scenario sounds very good. I just did not have the need of them, but I might some day. ___ 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 Oct 19, 2011, at 2:50 PM, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? And yes, this actually happened to me, one of us applied some pretty gradients to icons, while the other changed their shape... Kind regards, Remigiusz Modrzejewski ___ 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
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com I think that the veracity documentation totally deludes. :) But it may be intended, as it's a product of sourcegear. Eric wrote a book about it... and his message is (I think) buy the book. Actuallythey're giving the book away. I got a free copy in the mail a few weeks ago. Haven't read it yet though. http://www.ericsink.com/vcbe/index.html - look for request a free copy ___ 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 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Oct 19, 2011, at 2:50 PM, Stephan Beal wrote: My 0.02€: in some 16 years of using source control, i have never once had a use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they need them is still living in the 1980's or early 1990's. And now i say: open mouth, insert foot. Because... I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 4:44 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2011 03:52 PM, Stephan Beal wrote: Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). Tags apply to whole commits, though, not individual files. Perhaps lock/unlock actions should be implemented as a special commit that changes no file data, but changes a locked by foo property of the files in the manifest. Making them slightly funny commits would mean they appear in the history and are appropriately replicated, scoped to branches, and all that jazz. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6e54UACgkQRgz/WHNxCGoJpACcCb2CEFRnyD3QFLJF6cBqLpGm UHUAn2evRfMColj1Bi739+VrlDQXsj5l =PUux -END PGP 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] Veracity
On Wed, Oct 19, 2011 at 5:06 PM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: Tags apply to whole commits, though, not individual files. Perhaps Doh, you're right. And it sounded so simple. :/ -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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?
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.fr wrote: 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
[fossil-users] Locks (Was: Veracity)
This requires a lot of work on fossils part in order to be reliable. Unlike source changes, you can't do a commit and then require a merge before pushing if there's a collision. There are also nasty restrictions on how you do things. In particular, you have to have autosync on (or ignore it if off) and be connected to all repositories you push/pull from to use it. Given those restrictions, if you're looking to change things to support fossil, wouldn't you be better off using a tool designed for managing binaries ( an artifact repository) instead of one designed for managing textual sources? 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] Locks (Was: Veracity)
On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote: This requires a lot of work on fossils part in order to be reliable. Unlike source changes, you can't do a commit and then require a merge before pushing if there's a collision. There are also nasty restrictions on how you do things. In particular, you have to have autosync on (or ignore it if off) and be connected to all repositories you push/pull from to use it. Given those restrictions, if you're looking to change things to support fossil, wouldn't you be better off using a tool designed for managing binaries ( an artifact repository) instead of one designed for managing textual sources? I think fossil is a good tool for managing binaries too. And often binaries and textual sources better go together in a single repository. If I had to implement that on fossil, I'd use some kind of table like the shun table, propagated on autosync, that would ban a commit modifying a file. 'commit' could have a '--force', that would bypass the locks. I think they should be informative, and not restrictive. But it's not only locks alone that help, because that would depend on how often you sync, and you would notice new locks only when syncing, and that would be already late, because you may have already modified the file in your working directory, requiring a complex merge. Svn introduces the property of files of needs_lock. Those files, once checked out, are checked out in read-only into disk, and get the writeable state only if properly got a lock. Of course read-only-ness can be bypassed by the user owning the file, and that also has only an informative role. Maybe something like propagated tags could mark files as needs_lock, and act accordingly on updates/checkouts/... 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] Zenburn color theme for Fossil
Hi! Am 19.10.2011 um 03:10 schrieb Christopher Berardi: I think it would be a great idea to have some kind of repository where fossil users could share things like color schemes (or possibly extensions some day). Something along the lines of gnome-look.org. Wouldn't it be sufficient to run one Fossil instance for this purpose? Like in eat your own dogfood? Rolf: The theme reminds me of one of the builtin gvim themes (desert?). I butchered the Khaki, No Logo. skin that comes with Fossil. Visually, I like high contrast between background and text -- yellow, white, or green on black, white on blue, etci -- so the peach on grey is a little too subtle for my eyes to be comfortable with. But, I know some people who like that subtlety. From the zenburn readme: Zenburn is a low-contrast color scheme for Vim. It’s easy for your eyes and designed to keep you in the zone for long programming sessions. Of course keep you in the zone does not make a lot of sense for a website. I simply like the colorset. If we had the skins/themes in a public repository, anyone could fork and contribute a high contrast version. Thanks for sharing. Thank you all for providing Fossil in the first place! *bow* -rolf — Es kommt nicht darauf an wie du fällst. Sondern wie du aufstehst! ___ 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com the file, and that also has only an informative role. Maybe something like propagated tags could mark files as needs_lock, and act accordingly on updates/checkouts/... You found another use for propagating tags ;). As someone pointed out the original thread, fossil currently only allows tagging of commits, not files. Looking at the tagxref table, it's not clear to me whether that table supports (at least in principal) tagging individual files. If it does, tagging sounds like a good and simple solution to the advisory locking problem. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Zenburn color theme for Fossil
On Wed, Oct 19, 2011 at 7:16 PM, Rolf Meinecke fos...@jsilence.org wrote: Wouldn't it be sufficient to run one Fossil instance for this purpose? Like in eat your own dogfood? LOL! A skin-demo site could work if the anonymous user had the rights to change the skin. i don't think that will work right now without giving anonymous access to far more stuff (e.g. the css and header editors). Perhaps we could add a new permission which gives a user access to the skin-selection page. Doh, but then we have the problem that the skin is global. We'd need per-login session data to support that (a feature we've talked about a couple times but have no compelling need for). Of course keep you in the zone does not make a lot of sense for a website. I simply like the colorset. If we had the skins/themes in a public repository, anyone could fork and contribute a high contrast version. If you need a place to host such a repo, i can get one set up for you. *bow* Was that an intentional reference to the dogfood? ;) Es kommt nicht darauf an wie du fällst. Sondern wie du aufstehst! Was that the German translation of Batman's catchphrase in Batman Begins? What do we do when we fall down? We get back up. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Locks (Was: Veracity)
On Wed, Oct 19, 2011 at 07:27:56PM +0200, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com the file, and that also has only an informative role. Maybe something like propagated tags could mark files as needs_lock, and act accordingly on updates/checkouts/... You found another use for propagating tags ;). As someone pointed out the original thread, fossil currently only allows tagging of commits, not files. Looking at the tagxref table, it's not clear to me whether that table supports (at least in principal) tagging individual files. If it does, tagging sounds like a good and simple solution to the advisory locking problem. Well, the tags name or value could have the file name. Maybe, instead of tags, there could be a list like the versionable 'glob-ignore', of files that require locks. Those could be checked out with read-only permissions. That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com Well, the tags name or value could have the file name. That's an idea. But we would also need the branch, wouldn't we? Or does the tag follow the branch? Maybe, instead of tags, there could be a list like the versionable 'glob-ignore', of files that require locks. Those could be checked out with read-only permissions. That sounds reasonably simple to implement and is probably flexible enough to handle most cases (where people have either a few binary files of different types or large collections which all match a wildcard or two). That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. Can we do read-only cross-platform (i.e. Windows)? But the needs-lock tag also has the sync problem - the tag would need to be in place before the checkout. And update would be more complicated because fossil would have to temporarily overwrite (and potentially revert) the permissions in order to perform an update. Hmmm. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote: This requires a lot of work on fossils part in order to be reliable. If I had to implement that on fossil, I'd use some kind of table like the shun table, propagated on autosync, that would ban a commit modifying a file. 'commit' could have a '--force', that would bypass the locks. I think they should be informative, and not restrictive. But it's not only locks alone that help, because that would depend on how often you sync, and you would notice new locks only when syncing, and that would be already late, because you may have already modified the file in your working directory, requiring a complex merge. That's what I meant by a lot of work on fossils part to be reliable. Whether the lock command fails to create a lock or warns you if someone else has a lock is immaterial, they both take the same amount of work to figure out if someone else has a lock. If it isn't reliable, then it doesn't really solve the problem. And being reliable is a lot of work. No, I take that back. You could force locking to use a central server model. For each repository, you have to set a repository as the lock server. Using self or some such would mean You are the lock sever. The lock command could then either handle the lock locally, or request it from a remote server. Otherwise, you need a distributed lock manager, which is a hard enough problem to warrant it's own project. Svn introduces the property of files of needs_lock. Those files, once checked out, are checked out in read-only into disk, and get the writeable state only if properly got a lock. Of course read-only-ness can be bypassed by the user owning the file, and that also has only an informative role. Maybe something like propagated tags could mark files as needs_lock, and act accordingly on updates/checkouts/... SVN has a central server, thus avoiding the hard problem. Once you've got that, needs_lock is a good idea for a SCM that uses a change/commit workflow instead of the checkout/change/commit workflow. 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] Veracity
BTW, I just cloned Veracity source using veracity (vv) and realized that the repo consists of 13 sqlite DBs (WAL mode) + 1 external BLOB file (+ counting number simple sqlite3 files with containing table) On 19.10.2011 15:39, Lluís Batlle i Rossell wrote: On Wed, Oct 19, 2011 at 08:18:01AM -0400, Richard Hipp wrote: -- Forwarded message -- From: Yujianbinyujian...@huawei.com (2) support lock command, http://veracity-scm.org has this command. As Yujianbin mentions veracity... I saw some videos about veracity. From the web page, the author seems quite inspired by fossil, but on the presentation about veracity, he did not mention fossil at all. http://www.ericsink.com/entries/oscon_2011_video.html I saw that as a not fair presentation, on that regard. In any case, I wanted to try veracity, and for example it still lacks 'annotate', which for me is a basic command to have. Not that I like much its 'vv log' result either. The author also clearly said that veracity 'is not community software', so he is not going to accept regular contributions as his company develops the product, but he may accept patches. Whether to support locks... I think it can help some users, but I don't have use cases in my day to day. 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 ___ 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] Locks (Was: Veracity)
On Wed, Oct 19, 2011 at 07:41:56PM +0200, Stephan Beal wrote: That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. Can we do read-only cross-platform (i.e. Windows)? Microsoft filesystems have support for a special file attribute which controls whether the file should be considered read-only. It is advisory. ___ 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)
No -- please no locks! Remember, you are still free to use out-of-band mechanisms to contact the other developers to coordinate your activity: email, telephone, tweet, smoke signals, carrier pigeons, etc. On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Veracity (was: Fwd: suggestion on fossil)
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. Note that Fossil works just fine with binary files. Fossil's self-hosting repository contains binary files. (See, for example, www.fossil-scm.org/fossil/artifact/590c4da59eb) I keep a private repository of all my slide presentations that is almost all binary files. The only problem with binary files is that you cannot merge them. If you do introduce a fork on a binary file, that fork needs to be resolved manually. Locks do not help this - they do not magically enable merging. Locks just prevent the fork from happening in the first place. But Michael is right - that can be handled by administrative back-channels. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil)
I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync On check out 1. Files locked by others have write perms removed On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. Matt -=- On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Veracity (was: Fwd: suggestion on fossil)
I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a plane (without wifi, of course) and I want to edit a binary file, I'd be hosed because I wouldn't be able to push the lock to the central server. What if, like the Fossil main repo for example, there are two central servers? I do like your approach of a wrapper so that crazy lock stuff doesn't destroy the pristine awesomeness of Fossil itself. :-) On Wed, Oct 19, 2011 at 4:24 PM, Matt Welland estifo...@gmail.com wrote: I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync On check out 1. Files locked by others have write perms removed On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. Matt -=- On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Adding Fossil to Windows Explorer context menu?
On Wed, 19 Oct 2011 11:22:38 -0400, Tomek Kott tkott.s...@gmail.com wrote: For windows users, there is already an effort to get fossil extended to the explorer context menu. I think there's a need for a simple group + items that we can simply use through file managers like Windows Explorer without launching a full-fledged application. www.zhacks.com/2010/03/10/edit-7-zip-right-click-shell-context-menu/ Can someone confirm/infirm that a COM DLL is required for a group + items to be part of Windows' context menu? ___ 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: 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 ___ 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, Oct 20, 2011 at 1:45 AM, Joerg Sonnenberger jo...@britannica.bec.de wrote: 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. ...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. Yes, but with you, Richard meant fossil, generically. Any binary merge requires format-specific info which fossil cannot know. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 4:28 PM, Michael Barrow mich...@barrow.me wrote: I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a plane (without wifi, of course) and I want to edit a binary file, I'd be hosed because I wouldn't be able to push the lock to the central server. Sure it would help a little. If the files were previously locked then you *know* you are taking a risk making changes that may have to be discarded or tediously manually merged. If you knew you were likely to edit the files on the plane then mark them for edit while you still have Wifi at the airport. Then when your coworker goes to open them she will see that you have taken the edit lock and will know it is best to wait. Simple, clean and workable with fossil thanks to the (brilliant) autosync methodology. As described in another thread they are similar to a tag but at a file granularity and with the side effect of changing the write permission on the file. Again, lock is too strong a word. Think semaphore. You are just trying to make it easier for people to know who is working on what without a mass of tiresome one line emails such as don't edit the schematics today! What if, like the Fossil main repo for example, there are two central servers? Tags are synced between the two servers just fine right? I do like your approach of a wrapper so that crazy lock stuff doesn't destroy the pristine awesomeness of Fossil itself. :-) Agreed :) On Wed, Oct 19, 2011 at 4:24 PM, Matt Welland estifo...@gmail.com wrote: I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync On check out 1. Files locked by others have write perms removed On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. Matt -=- On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote: On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I seem to be still in the 80's... So how do you cope with edit conflicts on binary files today? i wasn't aware that people use them for binary files. i don't ever keep binary files in SCM, so i've never had that use case. Could a new special tag be used to implement lock-like behaviour? By special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 ___ 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, 19 Oct 2011 16:24:17 -0700 Matt Welland estifo...@gmail.com wrote: I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync Suggestion: If autosync is not enabled, treat this as an error. Override with -force. What happens if you find out that someone else has locked the file during the sync? Do you then revert all the changes you made and fail? On check out 1. Files locked by others have write perms removed So the lock is on the file, at all revisions? Are the same file on different branches considered different files in this case? On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure If locks aren't specific to a revision, shouldn't this happen on a pull (or the pull part of a sync) and not an update? On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. So long as you've got either one central server, or a collection of very tightly synchronized servers, it should help a lot. Here, tightly synchronized means synchronized much more frequently than pushes come in from developers. Personally, I still think this is a lot of work to go through to adopt one tool for a job that other tools are designed to do. Sort of like building a claw hammer fitting for a screwdriver. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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 8:46 PM, Mike Meyer m...@mired.org wrote: On Wed, 19 Oct 2011 16:24:17 -0700 Matt Welland estifo...@gmail.com wrote: I sent out a description of how I think light weight locks could be implemented on top of fossil in a past email. In fact I'm making some good progress on implementing what I want in a wrapper around fossil (implement locks in addition to some other things). I can look into making the wrapper available if anyone is interested. As has been mentioned Locks are really helpful when managing data that can't be automatically merged. However the need is not for draconian control but more of a semaphore to prevent accidentally changing a binary file at the same time someone else does. A more than adequate lock/semaphore methodology could be implemented on top of fossil roughly like the following... files have two flags; lockcontrolled and lockstate User locks file(s): fossil lock file1 file2 ... 1. Write permissions are removed 2. Lockcontrolled flag is set 3. Lockstate is set. 4. Sync Suggestion: If autosync is not enabled, treat this as an error. Override with -force. Good point. However using the wrapper I take over all calls to fossil and can do what is needed. If building this into fossil itself then the problem is a bit harder. What happens if you find out that someone else has locked the file during the sync? Do you then revert all the changes you made and fail? Terminology is a bit clumsy here. The word lock seems to get us in trouble. This is the model I'm implementing: termlockcontrolled lockstate writeable -- -- - - normal false don't care yes locked truetrueno unlockedtruefalse yes (only by locker) Going from normal to locked is the dangerous (as in potentially confusing) step. That step should be accompanied by an email for all to do a sync/update before and after. Going from locked to unlocked for edit is quite safe. The wrapper requests the unlock from the central repo and either gets it or not. Only if it gets the unlock does it open up permissions on the file and notify the user. This is not a distributed action (at least for my wrapper). On check out 1. Files locked by others have write perms removed So the lock is on the file, at all revisions? Are the same file on different branches considered different files in this case? The way I'm implementing it a path/file will be locked/unlocked for all branches and revisions. Of course this is not a big brother system, users are free to override and screw the other folks on the team. Such moves might be career limiting of course since they have enough information to do the right thing and a record is available as to what really happened. On commit 1. Changed locked files cause an error, override with -force On update 1. Update write permissions per the flags. 2. A locally changed locked file causes a merge failure If locks aren't specific to a revision, shouldn't this happen on a pull (or the pull part of a sync) and not an update? Yes, you are right. Keep in mind that I'm cheating in all this by keeping the lock data in a separate sqlite3 db and can manage the locks on every call to fossil. Doing the right thing as part of fossil itself would be a bit harder I think. On unlock for edit 1. If file not already locked 2. Update flags, sync 3. Open permissions Or something like that. I think the closely coupled agressive sync model fostered by fossil makes this very doable. So long as you've got either one central server, or a collection of very tightly synchronized servers, it should help a lot. Here, tightly synchronized means synchronized much more frequently than pushes come in from developers. Yes, very true. Personally, I still think this is a lot of work to go through to adopt one tool for a job that other tools are designed to do. Sort of like building a claw hammer fitting for a screwdriver. Good point. In fact we are using two systems in parallel for this very reason fossil and another system with rigorous locking. Using the wrapper for locking is really an experiment I'm doing on my own time that may well not pan out. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Veracity
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. On 10/19/2011 6:42 PM, Richard Hipp wrote: 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. Note that Fossil works just fine with binary files. Fossil's self-hosting repository contains binary files. (See, for example, www.fossil-scm.org/fossil/artifact/590c4da59eb http://www.fossil-scm.org/fossil/artifact/590c4da59eb) I keep a private repository of all my slide presentations that is almost all binary files. The only problem with binary files is that you cannot merge them. If you do introduce a fork on a binary file, that fork needs to be resolved manually. Locks do not help this - they do not magically enable merging. Locks just prevent the fork from happening in the first place. But Michael is right - that can be handled by administrative back-channels. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
