Re: [fossil-users] Stability of fossil test-name-to-id
'Lo. On 2014-08-19T21:17:18 +0200 Stephan Beal sgb...@googlemail.com wrote: You might be interested in a standalone alternative: ... and has already been created as a standalone binary with documented semantics: http://fossil.wanderinghorse.net/repos/libfossil/doxygen/fossil-core_8h.html#a265d03fe1e040d7068679f9b2a4d1a11 Looks good, certainly. Problem in my case is that I'd either have to write language bindings (as I'm not working from C), or require the person using my program to have installed your standalone utilities. I'm trying to stick to either calling the fossil binary directly, or piping SQL into fossil sqlite in the worst case. Am I to assume that test-name-to-id is definitely not to be depended upon? M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Stability of fossil test-name-to-id
On Wed, Aug 20, 2014 at 8:44 PM, org.fossil-scm.fossil-us...@io7m.com
wrote:
I'm trying to stick to either calling the fossil binary directly, or
piping SQL into fossil sqlite in the worst case.
Aha! ... i _thought_ we had an sqlite binding to that function, but
apparently we don't (libfossil does ;). i've added that to the todo list
(in the case that it really is missing), so you could so something like:
echo select sym2rid('trunk'); | fossil sqlite
echo select sym2uuid('trunk'); | fossil sqlite
Am I to assume that test-name-to-id is definitely not to be depended
upon?
Nothing named test- should be depended upon. Those are all tests written
during the implementations of various features. That particular one just
happens to be extraordinarily useful. We should certainly consider
upgrading it to real command status.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Stability of fossil test-name-to-id
On Wed, Aug 20, 2014 at 2:44 PM, org.fossil-scm.fossil-us...@io7m.com wrote: Am I to assume that test-name-to-id is definitely not to be depended upon? Probably test-name-to-id won't just go away. If you encounter problems, it will likely be because we enhance the command to output additional information, which then breaks your parsing logic. Or the command might be promoted to a supported command by removing the test- prefix. -- 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] Stability of fossil test-name-to-id
On Wed, Aug 20, 2014 at 8:50 PM, Stephan Beal sgb...@googlemail.com wrote:
Aha! ... i _thought_ we had an sqlite binding to that function, but
apparently we don't (libfossil does ;). i've added that to the todo list
(in the case that it really is missing), so you could so something like:
echo select sym2rid('trunk'); | fossil sqlite
echo select sym2uuid('trunk'); | fossil sqlite
Nevermind - now i see why we don't have one. The sqlite handle used by that
feature is not fossil-aware. The fossil global state gets shut down before
the sqlite shell is run (maintained as part of the sqlite project). So i
can't add this without a notable overhaul (which doesn't seem worth the
effort).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] available topologies for syncing and other misc questions
Everybody, This thread is sort of complete from my POV so I wanted to say thanks. It’s not that often I get so much good natured and usefull feedback on a mailing list. Fossil may not fit my dream use case (because of realtime issues mostly) But I have a few other cases where it could fit well. I’ll cut my teeth on it in the next few month thanks to you all. vBrgds, Charles. From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Stephan Beal Sent: 17 August 2014 12:39 To: Fossil SCM user's discussion Subject: Re: [fossil-users] available topologies for syncing and other misc questions On Sat, Aug 16, 2014 at 11:15 PM, Andy Bradford amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote: Once committed, it is not alterable, but it can be superceded with a special tag, but the original user will still be present in the manifest of the artifact. This user actually does not even need to be a Fossil user per se (in the database). For example, I could have a Fossil username of jack, but in my local clone of Fossil I configure the checkin user to be jill. All commits would have jill in them. The effect is similar if a user is renamed. All his old commits immutably refer to the old name, and Fossil has no mechanism with which to track user renames, meaning that consolidating reports (if you're into that type of thing) for both names has to be done by hand. However, all checkins would have the actual user in their manifest, and it is unalterable. Also note that Fossil stores the _names_, not IDs, when it does this. It's possible that users Bob and Jill have different IDs in any given clone. So, not only would you have to revert all the core repositories, you would have to revert all clones, everywhere, that might potentially have that huge commit. The only way to completely wipe out content from Fossil is via shunning: http://www.fossil-scm.org/index.html/doc/tip/www/shunning.wiki Even that may not actually wipe it out from all clones, however, as long as you leave the shun in place on the central repos, those clones will not be able to push the content again to the central repos. Shunning should be considered a last resort. It's intended to remove potential personal info, copyright violations, and stuff like that, not just for backing out a commit one didn't like. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author. ___ 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] available topologies for syncing and other misc questions
On Wed, Aug 20, 2014 at 4:16 PM, Charles Curtit charles.cur...@pgs.com wrote: This thread is sort of complete from my POV so I wanted to say thanks. It’s not that often I get so much good natured and usefull feedback on a mailing list. I think some of us here can thank you, too. Your scenario helps highlight real word situations where Fossil could be improved. Fossil may not fit my dream use case (because of realtime issues mostly) But I have a few other cases where it could fit well. I’ll cut my teeth on it in the next few month thanks to you all. For all of Fossil's limitations, I have found it to be the least hassle to set up and maintain, especially when factoring in the integrated (and distributed) ticket tracking, wiki and web interface. As for your near real time issues, I think either sync via cron or using Fossil's RSS feed to trigger sync would be able to fill your needs as I understand them. Good luck with your project. I suspect some of us will be curious about what you eventually do, even if not using Fossil. ___ 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] Stability of fossil test-name-to-id
On 2014-08-20T14:51:30 -0400 Richard Hipp d...@sqlite.org wrote: Probably test-name-to-id won't just go away. If you encounter problems, it will likely be because we enhance the command to output additional information, which then breaks your parsing logic. Or the command might be promoted to a supported command by removing the test- prefix. On 2014-08-20T20:50:26 +0200 Stephan Beal sgb...@googlemail.com wrote: Nothing named test- should be depended upon. Ok, thanks to you both! I'll use SQL for now. Needless to say, I'd love to see this become a supported command, ideally just producing a single artifact ID as output to avoid having to parse anything. I'm mainly just using this information to determine whether the tip of the repository has changed since I looked at it last. M ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
