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 wrote:
> On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment wrote:
>
>> I'm a novice Fossil user worki
Is there a way to do in from the command line?
2011/8/9 Lluís Batlle i Rossell
> On Tue, Aug 09, 2011 at 01:01:55PM -0500, tpero...@compumation.com wrote:
> > So, how do you move commits in the trunk to a new branch after the fact.
>
> Open the UI, click the checkin, then edit... and check the
I agree with the others, I usually start a branch as a part of the process
of working on some new feature. It just feels more organized than
remembering to decide what branch to use when I finally commit, or changing
the branch after the fact.
2011/8/9 Lluís Batlle i Rossell
> On Tue, Aug 09, 2
You sure jumped on that story fast!
I'm not Dr. Hipp, but since Fossil is based on a relational database while
UnQL is designed for non-relational databases, I doubt we'll see an UnQL
interface. Since UnQL is designed to mimic SQL, I'm not even sure what the
gain would be.
On Fri, Jul 29, 2011 a
d, Jul 13, 2011 at 6:56 PM, Joshua Paine wrote:
> On 7/13/2011 6:42 PM, Brian Cottingham wrote:
> > If the close command is removed is there still a need for 'open'?
>
> Truly no offense intended, Brian, but are you one of these newbies we're
> speaking about? `fossil
If the close command is removed is there still a need for 'open'? I'd
imagine with no close command a lot of newbies will ask "I opened my Fossil
repo and can't figure out how to close it".
On Wed, Jul 13, 2011 at 5:55 PM, Joshua Paine wrote:
> On 7/13/2011 5:48 PM, Brian Smith wrote:
> > I migh
n Wed, Jul 13, 2011 at 3:45 PM, Richard Hipp wrote:
>
>
> On Wed, Jul 13, 2011 at 3:33 PM, Brian Cottingham wrote:
>
>>
>> Should fossil close/open behave differently from fossil update? Is this a
>> bug in Fossil, or is it deliberate?
>>
>>
>>
> The be
xtras" my guess is
> file2
> > would be in that list.
>
> To change branches it is not necessary to 'close' the workspace.
> Just do
>
>fossil update
>
> That will properly remove/add/update the files in the workspace.
>
> >
> > Tom
When I switch between branches Fossil isn't removing files that belong to
the previous branch but not the current branch. Am I doing something wrong?
Example:
===
$ fossil new prj.fossil
project-id: 7e92eb48abd299ca1340a7bc0c86dba38097ad3e
server-id: 7efed910652f4fbceef4ec8cdcb152e7c944e7cc
admin
2011 at 11:28 AM, Stephan Beal wrote:
> On Wed, Jun 29, 2011 at 4:45 PM, Brian Cottingham wrote:
>
>> Would it be easy to add a check for openssl-devel to the build process to
>> provide a more helpful error message than the compile error?
>
>
> And what would the error be?
e launched on commit, and it only works with a
>> cygwin-aware
>> fossil. That is, fossil built on cygwin.
>>
>> It's trivial to build there.
>>
>> > On Tue, Jun 28, 2011 at 8:34 AM, Brian Cottingham > >wrote:
>> >
>> > > I'm
-Brian
On Tue, Jun 28, 2011 at 12:27 PM, Stephan Beal wrote:
> On Tue, Jun 28, 2011 at 6:22 PM, Brian Cottingham wrote:
>
>> Changing the path didn't work- I get the same "not recognized command"
>> error. I tried I didn't see a pre-compiled Cygwin version of
8, 2011 at 11:38 AM, Matt Welland wrote:
>
>> Are you using fossil compiled for cygwin or fossil compiled for windows?
>> If the later then internally it will not know about cygwin paths and may not
>> be able to launch cygwin binaries (not sure on that one, haven't tested it).
I'm using Fossil from a Cygwin terminal and I can't get the gdiff command to
work with vimdiff. I've tried setting gdiff-command to "vimdiff" but running
"fossil gdiff" I get "'vimdiff' is not recognized as an internal or external
command". I tried setting the command to "/usr/bin/vimdiff" but I ge
14 matches
Mail list logo
