On Tue, May 14, 2013 at 1:31 AM, Miles Fidelman
wrote:
> Yes, but for collaborative document writing, something more like a full
> wiki, is just that much nicer. So close, but...
>
> Can't have everything, I guess.
If you haven't tried Google Docs, give it a try and prepare to be blown
away. i'
Richard Hipp wrote:
On Mon, May 13, 2013 at 4:43 PM, Andy Bradford
mailto:amb-fos...@bradfords.org>> wrote:
Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400:
> I also wonder if it effected the choice of whether to use
fossil or
> not for various projects. I k
On Mon, May 13, 2013 at 6:47 PM, Andy Bradford <
amb-sendok-1371077232.ipnkckchbfagchdof...@bradfords.org> wrote:
> Is
> customization of the menu in the web UI possible?
>
Of course. Visit Admin->Header to edit the TH1 script that generates the
header. It isn't hard.
You can modify the CSS
Thus said Richard Hipp on Mon, 13 May 2013 16:57:08 -0400:
> On Mon, May 13, 2013 at 4:43 PM, Andy Bradford wrot
e:
>
> > One can always version control the documents in a separate directory
> > called docs. ;-) Of course it won't be served up via Wiki,
>
> Sure it can. See
> http://www.foss
On Mon, May 13, 2013 at 4:43 PM, Andy Bradford wrote:
> Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400:
>
> > I also wonder if it effected the choice of whether to use fossil or
> > not for various projects. I know that, personally, there are a few
> > places that I've wanted
Thus said Miles Fidelman on Mon, 13 May 2013 16:09:30 -0400:
> I also wonder if it effected the choice of whether to use fossil or
> not for various projects. I know that, personally, there are a few
> places that I've wanted to START with versioned documentation, and
> would have
Lluís Batlle i Rossell wrote:
On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote:
On Mon, May 13, 2013 at 10:41 AM, Andy Bradford wrote:
When I first learned about fossil and the integrated tickets/wiki, I
assumed that both of these features were also version controlled just
l
On Mon, May 13, 2013 at 5:10 PM, Lluís Batlle i Rossell wrote:
> I've the feeling that the question had come up before, but simply noone
> developed a solution.
>
The topic has come up once or twice before, but the threads have been short
and i don't think anyone ever actually voiced it in the fo
On Mon, May 13, 2013 at 10:58:04AM -0400, Richard Hipp wrote:
> On Mon, May 13, 2013 at 10:41 AM, Andy Bradford
> wrote:
>
> >
> > When I first learned about fossil and the integrated tickets/wiki, I
> > assumed that both of these features were also version controlled just
> > like any oth
On Mon, May 13, 2013 at 10:41 AM, Andy Bradford wrote:
>
> When I first learned about fossil and the integrated tickets/wiki, I
> assumed that both of these features were also version controlled just
> like any other might that might exist in the repository.
The Wiki is version controlled
Thus said Stephan Beal on Mon, 13 May 2013 11:04:23 +0200:
> While i'm not at all against the idea of upgrading the wiki pages to
> full-fledged content, i just want to point out that this feature
> would affect more than the www GUI: the (fossil wiki commit) and
> (/json/wiki/save)
On Mon, May 13, 2013 at 11:04:23AM +0200, Stephan Beal wrote:
> On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell
> wrote:
>
> > A simple operation (similar to edit, just with the merge conflicts) could
> > allow
> > merging multiple leaves.
> >
> > What do you think?
>
>
> While i'm not
On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell
wrote:
> A simple operation (similar to edit, just with the merge conflicts) could
> allow
> merging multiple leaves.
>
> What do you think?
While i'm not at all against the idea of upgrading the wiki pages to
full-fledged content, i just
On Wed, May 08, 2013 at 07:28:59AM -0400, Richard Hipp wrote:
> On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell
> wrote:
>
> > I don't see why most VCS tend (somehow propose) to *not commit* merge
> > conflicts before solving the conflicts. That makes the conflict solution
> > 'disappear'
This is true and a good reason to not commit non-working code but for those
times where it inadvertently happens it would be nice to have the
equivalent of gits "bisect skip".
On Wed, May 8, 2013 at 4:28 AM, Richard Hipp wrote:
>
>
> On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell
> wro
On 2013-05-08 6:52, Stephan Beal wrote:
fork all of them).
Fork 'em all and let God sort it out.
:)
--
Thanks,
DougF (KG4LMZ)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo
On Wed, May 08, 2013 at 07:28:59AM -0400, Richard Hipp wrote:
> On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell
> wrote:
>
> > I don't see why most VCS tend (somehow propose) to *not commit* merge
> > conflicts before solving the conflicts. That makes the conflict solution
> > 'disappear'
On Wed, May 8, 2013 at 6:56 AM, Lluís Batlle i Rossell wrote:
> I don't see why most VCS tend (somehow propose) to *not commit* merge
> conflicts before solving the conflicts. That makes the conflict solution
> 'disappear' from the timeline.
>
One reason: Having non-working code in the tree makes
On Wed, May 08, 2013 at 01:01:42PM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 12:56 PM, Lluís Batlle i Rossell
> wrote:
>
> > In fact, I don't see why most VCS tend (somehow propose) to *not commit*
> > merge
> > conflicts before solving the conflicts. That makes the conflict solution
>
On Wed, May 8, 2013 at 12:56 PM, Lluís Batlle i Rossell wrote:
> In fact, I don't see why most VCS tend (somehow propose) to *not commit*
> merge
> conflicts before solving the conflicts. That makes the conflict solution
> 'disappear' from the timeline.
>
> I think it's fine in committing the conf
On Wed, May 08, 2013 at 12:52:17PM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 12:28 PM, Lluís Batlle i Rossell
> wrote:
>
> > One thing is not be able to merge; the other is losing information
> > silently.
> > Very annoying.
> >
>
> It's not lost, per se, but it is (annoyingly) hidden
On Wed, May 8, 2013 at 12:28 PM, Lluís Batlle i Rossell wrote:
> One thing is not be able to merge; the other is losing information
> silently.
> Very annoying.
>
It's not lost, per se, but it is (annoyingly) hidden in that case. The main
www UI doesn't (AFAIR) offer any features for browsing spe
On Wed, May 08, 2013 at 10:20:07AM +0200, Stephan Beal wrote:
> On Wed, May 8, 2013 at 9:34 AM, Oliver Friedrich wrote:
>
> > We now have discovered that wiki-pages seem to be not synchronized, but
> > only always used from the last edit. That leads us to some difficulties,
> > editing a wiki-pag
On Wed, May 8, 2013 at 9:34 AM, Oliver Friedrich wrote:
> We now have discovered that wiki-pages seem to be not synchronized, but
> only always used from the last edit. That leads us to some difficulties,
> editing a wiki-page on both front-repositories - loss of first edit.
>
> How is the best w
Hello Fossil-Users,
I have a question regarding the wiki-functionality of a fossil-repository.
Our current setup we use to have a subsequent repository for our sub-team in a greater process, consists of one basic backbone-repository, wich is permanently syncec (5 minutes) with two front-rep
25 matches
Mail list logo
