On Feb 26, 2012, at 15:00 , Leo Razoumov wrote:
> On Sun, Feb 26, 2012 at 04:48, Stephan Beal wrote:
>> On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov wrote:
>>>
>>> I sincerely hope that fossil was not designed with only one work-flow
>>> (SQLite and fossil) in mind. Am I mistaken?
>>
>>
>>
On Sun, Feb 26, 2012 at 04:48, Stephan Beal wrote:
> On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov wrote:
>>
>> I sincerely hope that fossil was not designed with only one work-flow
>> (SQLite and fossil) in mind. Am I mistaken?
>
>
> If i'm not sorely mistaken, fossil was indeed originally desig
On Sat, 25 Feb 2012 15:48:10 -0500
Leo Razoumov wrote:
> I hope that you realize that one size fits all is not a good design
> principle for a general purpose tool.
/me nods
> And yes, I do need my private space for private experimentation. For
> instance I keep some branches where code does no
On Sat, Feb 25, 2012 at 9:48 PM, Leo Razoumov wrote:
> I sincerely hope that fossil was not designed with only one work-flow
> (SQLite and fossil) in mind. Am I mistaken?
>
If i'm not sorely mistaken, fossil was indeed originally designed for
exactly one purpose: managing the sqlite repo.
--
-
On Sat, 25 Feb 2012 18:22:44 -0500
Leo Razoumov wrote:
> Be aware that "fossil scrub --private" will remove *ALL* your private
> branches including the ones you created for some other purposes.
Yeah, "all or nothing".
So, I'm pleased to be able to get rid of unwanted exeprimental stuff
whose va
On Sat, Feb 25, 2012 at 09:17, Richard Hipp wrote:
> A key philosophical design principle of Fossil is "no erasures". This is
> how business financial accounting is (or used to be) done. You write in
> ink. If an error is found, you annotate the erroneous entry with a note of
> correction and/o
On Sat, 25 Feb 2012 09:17:57 -0500
Richard Hipp wrote:
> A key philosophical design principle of Fossil is "no erasures".
> This is how business financial accounting is (or used to be) done.
> You write in ink. If an error is found, you annotate the erroneous
> entry with a note of correction an
On Sat, Feb 25, 2012 at 18:17, Gour wrote:
>
> Heh today after more detailed reading of the docs, I've 'found out'
> that "fossil scrub --private" might be good enough as replacing hg's MQ
> extension...Was absent the whole day and will try tomorrow.
>
Be aware that "fossil scrub --private" will
On Sat, 25 Feb 2012 06:48:59 -0500
Leo Razoumov wrote:
> For the most part I use private branches as for-my-eyes-only throw
> away temporaries which are cleansed with "fossil scrub".
Heh today after more detailed reading of the docs, I've 'found out'
that "fossil scrub --private" might be good e
On Sat, Feb 25, 2012 at 09:17:57AM -0500, Richard Hipp wrote:
>For contributing to Fossil itself, there is a Pre-checkin Checklist that
>developers are suppose to follow prior to each 'fossil commit". (A
>similar checklist exists for SQLite.) A key element of this checklist is
>th
On Sat, Feb 25, 2012 at 14:19, Eric wrote:
>
> On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote:
>> I am fine with this philosophy of "no-rewriting" of published history.
>> And I am *not* asking for a "git rebase" equivalent.
>>
>> But I have to follow a work-flow that consists of a cascade
On Sat, February 25, 2012 5:44 pm, Leo Razoumov wrote:
> On Sat, Feb 25, 2012 at 09:17, Richard Hipp wrote:
>>
>> A key philosophical design principle of Fossil is "no erasures". This
>> is
>> how business financial accounting is (or used to be) done. You write in
>> ink.
>
> I am fine with thi
On Sat, Feb 25, 2012 at 09:17, Richard Hipp wrote:
>
> A key philosophical design principle of Fossil is "no erasures". This is
> how business financial accounting is (or used to be) done. You write in
> ink.
I am fine with this philosophy of "no-rewriting" of published history.
And I am *not*
On Sat, Feb 25, 2012 at 2:26 AM, Gour wrote:
> Right. I'd like to have simple 'rollback' as well in a situation when I
> quickly find out that the commit was simply mistake...
>
A key philosophical design principle of Fossil is "no erasures". This is
how business financial accounting is (or use
On Sat, Feb 25, 2012 at 02:26, Gour wrote:
> On Fri, 24 Feb 2012 18:13:15 -0500
> Leo Razoumov wrote:
>
>> One thing that I miss in fossil above everything else is inability to
>> push/pull individual branches or/and individual artifacts. This is
>> really big item on my wish list. Current fossil
On Fri, 24 Feb 2012 18:13:15 -0500
Leo Razoumov wrote:
> Actually I stand corrected.
>
> $ fossil diff --new-file --from P1-parent --to P3 | patch -E
>
> should add/remove text files automatically. Binary files, on the other
> hand still pose a problem.
OK. Thanks.
> I used Hg briefly few
On Fri, Feb 24, 2012 at 15:12, Gour wrote:
> On Fri, 24 Feb 2012 08:55:09 -0500 Leo Razoumov wrote:
>> If the code above does not work you can try poor-man's approach with
>> the patch (untested)
>>
>> fossil co E
>> fossil diff --from P1-parent --to P3 | patch
>> Â
>> Please, be aware that "pa
On Fri, 24 Feb 2012 08:55:09 -0500
Leo Razoumov wrote:
> In git --rebase it is known as patch squashing.
I'm not familiar with git...
> Could you, try the following (untested)
> fossil update E
> fossil merge --cherrypick P1
> fossil merge --cherrypick P2
> fossil merge --cherrypick P3
> fossi
On Fri, Feb 24, 2012 at 02:53, Gour wrote:
> On Fri, 10 Feb 2012 15:46:15 -0500
> Leo Razoumov wrote:
>
>> I am sorry if my language was not clear. Here are the diagrams:
>
> I am sorry to jump in this thread...we might soon start working on our
> application which is meant for niche market and t
On Fri, 10 Feb 2012 15:46:15 -0500
Leo Razoumov wrote:
> I am sorry if my language was not clear. Here are the diagrams:
I am sorry to jump in this thread...we might soon start working on our
application which is meant for niche market and therefore potential
contributors although experts in the
On Fri, Feb 10, 2012 at 18:38, Richard Hipp wrote:
>
>
> On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov wrote:
>>
>> I hope that fossil could pre-populate the message with the
>> text from the commit that is being cherry-picked. It would save lots
>> of typing.
>>
>
> A very reasonable suggestion.
On Fri, Feb 10, 2012 at 4:48 PM, Leo Razoumov wrote:
> I hope that fossil could pre-populate the message with the
> text from the commit that is being cherry-picked. It would save lots
> of typing.
>
>
A very reasonable suggestion. The latest trunk version of fossil does
this. http://www.fossil
On Fri, Feb 10, 2012 at 16:15, Richard Hipp wrote:
>
>
> On Fri, Feb 10, 2012 at 4:07 PM, Leo Razoumov wrote:
>>
>> On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote:
>> >
>> > fossil update D
>> > fossil merge --cherrypick P1
>> > fossil commit --branch P1p
>> > fossil merge --cherrypick P2
>>
On Fri, Feb 10, 2012 at 4:07 PM, Leo Razoumov wrote:
> On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote:
> >
> > fossil update D
> > fossil merge --cherrypick P1
> > fossil commit --branch P1p
> > fossil merge --cherrypick P2
> > fossil commit --tag P2p
> > fossil merge --cherrypick P3
> > foss
On Fri, Feb 10, 2012 at 15:54, Richard Hipp wrote:
>
> fossil update D
> fossil merge --cherrypick P1
> fossil commit --branch P1p
> fossil merge --cherrypick P2
> fossil commit --tag P2p
> fossil merge --cherrypick P3
> fossil commit --tag P3p
>
Richard,
thanks for the suggestion. Will I have to
On Fri, Feb 10, 2012 at 3:46 PM, Leo Razoumov wrote:
> On Fri, Feb 10, 2012 at 15:28, Richard Hipp wrote:
> > On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov
> wrote:
> >>
> >> I guess at some point with every SCM system one faces a challenge of
> >> a patch based workflow. I need to maintain a
On Fri, Feb 10, 2012 at 15:28, Richard Hipp wrote:
> On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov wrote:
>>
>> I guess at some point with every SCM system one faces a challenge of
>> a patch based workflow. I need to maintain a set of patches on a
>> branch which are periodically reapplied as t
On Fri, Feb 10, 2012 at 3:19 PM, Leo Razoumov wrote:
> I guess at some point with every SCM system one faces a challenge of
> a patch based workflow. I need to maintain a set of patches on a
> branch which are periodically reapplied as trunk moves forward.
If you apply a patch once, it is on t
I guess at some point with every SCM system one faces a challenge of
a patch based workflow. I need to maintain a set of patches on a
branch which are periodically reapplied as trunk moves forward. Git
has "git rebase", Mercurial has "hg mq". What solution does fossil
offer?
--Leo--
_
29 matches
Mail list logo
