Thus said Andy Bradford on 09 Sep 2014 22:22:43 -0600:
It seems like this should work, but I haven't found the right
combination of permissions yet.
As it turns out, this just doesn't seem possible with Fossil currently.
Would there be any interest in something like:
$ f diff
Index:
On 9-9-2014 8:28, Stephan Beal wrote:
On Tue, Sep 9, 2014 at 8:25 AM, Tony Papadimitriou to...@acm.org
mailto:to...@acm.org wrote:
So, I would like to see this improvement, if possible: Once
launched, the window to come in front of other windows, and its
position to be always
A separate (doc-specific) repo?
- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity and
typos.
On Sep 10, 2014 8:26 AM, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said Andy Bradford on 09 Sep 2014 22:22:43 -0600:
It seems like this should work, but
Thus said Stephan Beal on Wed, 10 Sep 2014 08:38:06 +0200:
A separate (doc-specific) repo?
Basically, yeah, but I don't want users to have access to the history of
changes (e.g. no timeline, no diffs, etc...), only Wiki and Embedded
Docs. And I don't want anonymous users---which means I
On Wed, Sep 10, 2014 at 8:31 AM, Martijn Coppoolse
li...@martijn.coppoolse.com wrote:
On 9-9-2014 8:28, Stephan Beal wrote:
On Tue, Sep 9, 2014 at 8:25 AM, Tony Papadimitriou to...@acm.org
mailto:to...@acm.org wrote:
So, I would like to see this improvement, if possible: Once
Thus said Andy Bradford on 10 Sep 2014 00:26:12 -0600:
As it turns out, this just doesn't seem possible with Fossil
currently. Would there be any interest in something like:
Or how about something like this:
$ f diff
Index: src/login.c
2014-09-08 18:50 GMT+02:00 Joe Mistachkin j...@mistachkin.com:
I would appreciate reviews of the following branches for inclusion in trunk:
https://www.fossil-scm.org/index.html/timeline?r=xferUuidList
One more branch which is ready to be reviewed for inclusion in trunk:
Joe Mistachkin
What are the values of the global Fossil settings matching tcl* and
th1*?
Does the output of fossil all list and fossil all list --ckout make
sense to you?
Hello Joe,
thank you for valuable tips and suggestions. With that I was able to locate
where the problem was.
I had invalid
On Wed, Sep 10, 2014 at 5:00 AM, Jan Nijtmans jan.nijtm...@gmail.com
wrote:
2014-09-08 18:50 GMT+02:00 Joe Mistachkin j...@mistachkin.com:
I would appreciate reviews of the following branches for inclusion in
trunk:
https://www.fossil-scm.org/index.html/timeline?r=xferUuidList
Does anyone have any experience with hooking up fossil to JIRA?
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I wish to migrate several bzr repos to fossil 1.29, and have gotten
stuck at fossil telling me cannot handle R records, use --full-tree
trying to import the fast-import dumps. Is there a workaround for this
issue? I have seen only one reference to this issue on this ML, from
last May, but no
On Wed, Sep 10, 2014 at 11:38 AM, Dömötör Gulyás dognot...@gmail.com
wrote:
I wish to migrate several bzr repos to fossil 1.29, and have gotten
stuck at fossil telling me cannot handle R records, use --full-tree
trying to import the fast-import dumps. Is there a workaround for this
issue? I
On Wed, Sep 10, 2014 at 9:26 AM, Eric Rubin-Smith eas@gmail.com wrote:
Does anyone have any experience with hooking up fossil to JIRA?
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
My
On Wed, Sep 10, 2014 at 6:12 PM, Ron W ronw.m...@gmail.com wrote:
like this could reasonably be accomplished with some combination of the
JSON API and the TCL integration.
And suggestions to either in order to make them usable for such purposes
are of course welcomed. :)
That said: ticket
Ron W wrote:
Does anyone have any experience with hooking up fossil to JIRA?
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
I guess I meant the former, though the latter is
Stephan Beal wrote:
That said: ticket integration with the JSON API turned out to be a lot
more work than anticipated (and thus it is quite castrated) because of
the customizability of the ticket subsystem and its close relationship to
the scripting world. Thus, i suspect, the TCL/TH1
As a separate question along those lines, have people had other sorts of
trouble (IT, data sanity or otherwise) with git+JIRA?
Sorry to self-reply. I meant for the sense of this question to be
constrained
specifically to the git-to-JIRA hooks or JIRA itself -- not to git as a
stand-alone
On Wed, Sep 10, 2014 at 12:21 PM, Stephan Beal sgb...@googlemail.com
wrote:
That said: ticket integration with the JSON API turned out to be a lot
more work than anticipated (and thus it is quite castrated) because of the
customizability of the ticket subsystem and its close relationship to
Stephan Beal wrote:
In principal, plain old transport is not the problem. The problem (as i
recall it, though it's been a while and i've got the memory of a goldfish)
was that i could not define a concrete structure for JSON/Ticket I/O
because tickets are customizable. Suggestions are
On Wed, Sep 10, 2014 at 6:44 PM, Eric Rubin-Smith eas@gmail.com wrote:
If we assume for a moment that the user is willing to customize the
Fossil ticket system to exactly match whatever is needed to integrate
with JIRA, does the problem become easy overall?
To answer that i'd need to
On Wed, Sep 10, 2014 at 6:35 PM, Ron W ronw.m...@gmail.com wrote:
But given that an integration with an external issue tracker would,
itself, have to be customisable, I am hoping that the JSON API can at least
transport the custom fields. If it were also possible to query the
On Wed, Sep 10, 2014 at 12:27 PM, Eric Rubin-Smith eas@gmail.com
wrote:
Ron W wrote:
Do you mean automatic ticket sync between Fossil and an external issue
tracking system? Or using an external issue tracking system instead of
Fossil's?
I guess I meant the former, though the latter
On Wed, Sep 10, 2014 at 12:44 PM, Eric Rubin-Smith eas@gmail.com
wrote:
If we assume for a moment that the user is willing to customize the
Fossil ticket system to exactly match whatever is needed to integrate
with JIRA, does the problem become easy overall?
As I understand it, Jira is
On Wed, Sep 10, 2014 at 12:38 PM, Stephan Beal sgb...@googlemail.com
wrote:
In principal, plain old transport is not the problem. The problem (as i
recall it, though it's been a while and i've got the memory of a goldfish)
was that i could not define a concrete structure for JSON/Ticket I/O
On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote:
Is it not possible to define an open-ended list of name-value pairs?
i've forgotten the English word (and maybe there isn't one): jein
Sure we can, but then we've got a data format nobody can predict, which
doesn't sit well
Petr Ferdus wrote:
One visual clue was that fossil status line in footer stopped to provide
TCL related info.
(I cant recall, where I got it from but it is quite useful)
I actually wrote that. It's part of the Fossil Enhanced Default style
footer.
--
Joe Mistachkin
I have windows version of fossil build on [c91bafccb5] compiled and enabled
with TH1_DOCS,
TH1_HOOKS and TCL.[1] I run it locally as a server[2]. I am experimenting with
test
repo testtcl.fossil with all tc*, th1* settings allowed and mostly clear[3]
I like to explore TH1_DOCS feature. How
Petr Ferdus wrote:
What might block ckout feature?
First, you should be aware that enabling the th1-docs setting on a
repository basically
implies that all people with check-in privileges are implicitly trusted.
That is why it
is disabled by default at compile-time and runtime.
If you
Hi all,
I have a question about how to properly use branches in the following
scenario:
I have version 1.0 of my software, which is stable. Then I want to start
developing version 2. Initially I make a version2 branch where all
development happens, while at the same time I continue to
On Wed, Sep 10, 2014 at 7:50 PM, Philip Bennefall phi...@blastbay.com
wrote:
Hi all,
I have a question about how to properly use branches in the following
scenario:
I have version 1.0 of my software, which is stable. Then I want to start
developing version 2. Initially I make a version2
Thanks, Richard! I really appreciate the detailed response. Many of the
practices you describe, I am already following such as tagging each
release with both release and the version number. It makes things really
easy when going back to fix bugs, answer support queries about the given
version
On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote:
Sometimes we will make a check-in to trunk then later decide it doesn't
belong there, so then move it into a branch. (
Isn't this only possible if no further commits have been made on the trunk?
I suppose one possible fix
On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com wrote:
On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote:
Sometimes we will make a check-in to trunk then later decide it doesn't
belong there, so then move it into a branch. (
Isn't this only possible
On Wed, Sep 10, 2014 at 8:47 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Sep 10, 2014 at 10:48 PM, Matt Welland estifo...@gmail.com
wrote:
On Wed, Sep 10, 2014 at 5:12 PM, Richard Hipp d...@sqlite.org wrote:
Sometimes we will make a check-in to trunk then later decide it doesn't
I use symlinks very heavily; I'm trying to convert all my world to
fossil, but I can't get symlinks to work.
Here's a transcript:
: Daves-MacBook-Retina-784 ; ls -l current current/cmf.html
lrwxr-xr-x 1 dmason staff 5 Sep 9 22:42 current - f2014
-rwxr-xr-x 1 dmason staff
Thus said David Mason on Thu, 11 Sep 2014 00:42:09 -0400:
: Daves-MacBook-Retina-784 ; cat .fossil-settings/allow-symlinks
yes
: Daves-MacBook-Retina-784 ; fs ci -m test
New_Version: 240dcb9a36ff5fde1c3bc1ae1e906dbb479b3698
I could be wrong, but I don't think the .fossil-settings apply
36 matches
Mail list logo
