Re: [fossil-users] how to maintain a set of patches?

[Remigiusz Modrzejewski]

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?
>> 
>> 
>> If i'm not sorely mistaken, fossil was indeed originally designed for
>> exactly one purpose: managing the sqlite repo.
>> 
> 
> GIT was originally designed as a BitKeeper replacement for linux
> kernel. Then the scope broadens...

Well, IIRC Mercurial was even more narrow, originally created to keep only some 
subsystem of the kernel ;)


Kind regards,
Remigiusz Modrzejewski



___
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] how to maintain a set of patches?

[Leo Razoumov]

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 designed for
> exactly one purpose: managing the sqlite repo.
>

GIT was originally designed as a BitKeeper replacement for linux
kernel. Then the scope broadens...

--Leo--
___
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] how to maintain a set of patches?

[Gour]

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 not yet compile. But the
> branches that I push to TEAM.fossil should pass a "red face test",
> they should at least compile OK.

I also find reasonable not to clutter team members' repos with my
half-baked experiments.

> I sincerely hope that fossil was not designed with only one work-flow
> (SQLite and fossil) in mind. Am I mistaken?

Yeah...Fossil is very refreshing tool, beating many apps by its
simplicity, but "Everything should be made as simple as possible, but
not one bit simpler."


Sincerely,
Gour


-- 
The embodied soul may be restricted from sense enjoyment, 
though the taste for sense objects remains. But, ceasing 
such engagements by experiencing a higher taste, 
he is fixed in consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Stephan Beal]

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.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] how to maintain a set of patches?

[Gour]

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 valuable parts are committed to the trunk, but having ability to
be selective would be great.

In a similar manner as 'fossil scrub' warns user with:

Scrubbing the repository will permanently information.
Changes cannot be undone.  Continue (y/N)? y

I believe that same thing could be done by implementing 'fossil
rollback' and having ability to push selective branches while still
making Fosill as exceptionally robust & reliable DVCS, but those
additional features would make it top-notch DVCS suitable for (more=
power users as well...that's finally what I like in Mercurial: quite
decent & safe defaults, but giving more power for those who need it and
when is needed.


Sincerely,
Gour

-- 
Perform your prescribed duty, for doing so is better than not 
working. One cannot even maintain one's physical body without work.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Leo Razoumov]

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/or create new entries to undo the mistake.  You do not erase
> or alter existing entries.  And in this way one maintains an audit trail.
>

I agree that the concept of non-rewritable history in a given
repository is a good thing. But it should not preclude ability to
export a subset of history (a fully connected component of the
original DAG) as  a separate repository (might be even with a
different project-ID).
If I have a book "History of the World" I should be able to take a
chapter on American History and publish it as a book "History of the
USA".

--Leo--
___
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] how to maintain a set of patches?

[Gour]

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 and/or create new entries to undo the
> mistake.  You do not erase or alter existing entries.  And in this
> way one maintains an audit trail.

That's clear.

> That said, I'm not completely opposed to having the ability to back
> out a mistaken commit, so long as that commit has not been pushed or
> synced to other repositories.  

This is very inspiring to hear.

Darcs is my 1st DVCS and very early I had to learn the lesson that
rollback is useful only as long as the pathes haven't escaped out in the
wild.

> It is DAG editing (rewriting history) that I am opposed to.  

Here I fully agree with you.

> Rewriting history (rebase) and omitting parts of history (rolling back
> commits) are distinct concepts, and rewriting (lying) is clearly a
> greater sin than omitting irrelevancies.  

Although there is rebase for Mercurial I am not at all thinking about
using it 'cause having 'unfinished' patches handled by MQ and commiting
them when ready is also what we need...although latest Mercurial did get
'phases support' feature which is touched by Leo in 'feature proposal:
explicitly public branches' thread.

> But most Fossil users operate in autocommit mode, meaning that commit
> and push happen together, so there is seldom exist any unsynced
> commits, which is perhaps the biggest reason why rollback has never
> been implemented.

Well, I expect from the nicely crafted tool to allow me to circumvent
its default route of operation by transferring responsibilities for the
action to me.

So, if you implement rollback and I do something stupid, I promise here
that, unlike Zed, I won't neither blame you nor Fossil. ;)


Sincerely,
Gour


-- 
A person who is not disturbed by the incessant flow of 
desires — that enter like rivers into the ocean, which is 
ever being filled but is always still — can alone achieve 
peace, and not the man who strives to satisfy such desires.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Leo Razoumov]

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 remove *ALL* your private
branches including the ones you created for some other purposes.

--Leo--
___
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] how to maintain a set of patches?

[Gour]

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 enough as replacing hg's MQ
extension...Was absent the whole day and will try tomorrow.

> Recently Brian Smith announced on this list that he is working on
> limsync fossil extension that allows to push/pull individual branches.
> http://code.linuxfood.net/pub/repo/fossil-limsync
> The code is still experimental and has some issues but hopefully it
> will stabilize soon.

That would be *very* nice thing.


Sincerely,
Gour

-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Christopher Berardi]

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
>the "fossil diff" - to make sure you really know what you are about to
>check in.  Very often I spot debugging statements that should have been
>removed, missing or erroneous comments, bad indentation, or goofy variable
>names during that "fossil diff" step, and thus have an opportunity to
>correct those errors prior to making them a part of the permanent record. 
>I also find that I am able to write better checkin comments if I have just
>reviewed all changes associated with the checkin.  I highly recommend that
>you adopt some kind of short, simple pre-checkin checklist for your
>projects as well, and that this checklist involve a "diff" of what is
>about to be checked in.  It really does help.

Is the 'pre-checkin checklist' for fossil and sqlite publicly documented
somewhere? This sounds like a good development habit to get into and it
would be nice to maybe have a template to start from.

-- 
Christopher Berardi
http://www.natoufa.com/

May grace and peace by yours in abundance.
___
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] how to maintain a set of patches?

[Leo Razoumov]

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 of
>> repositories.
>
> "have to"? Why? Is this a case of having to step back and look at the aim
> of the workflow rather than assuming that it is set in stone?
>

Eric,
I hope that you realize that one size fits all is not a good design
principle for a general purpose tool.

>> (1) PRV.fossil -- is my private repo where all my dirty laundry is stored
>
> Do you need a repository for this? A repository is not a backup tool.

I never mentioned backup, did I?
And yes, I do need my private space for private experimentation. For
instance I keep some branches where code does not yet compile. But the
branches that I push to TEAM.fossil should pass a "red face test",
they should at least compile OK.

>> (2) TEAM.fossil -- this is a place shared by the development team.
>> Mistakes can be annotated as "mistake" and backed out as you said.
>
>> (3) PUBLIC.fossil -- is a clean and shiny final result that must be
>> devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos.
>
> Why do you need (3)? Who are you hiding stuff from? I think a clean branch
> is all you need.

First and for most, this project is company internal. But some
versions are exported outside to our external collaborators.
For variety of reasons that are beyond of my control MY.fossil,
TEAM.fossil and PUBLIC.fossil have to be separate.

As a new fossil user I posted a question to this list on how can I
establish cascading work-flow using fossil.
I would appreciate if someone could tell me whether it is possible or not.
I am looking for a tool that helps me and my team to do the work in my
environment.
I sincerely hope that fossil was not designed with only one work-flow
(SQLite and fossil) in mind. Am I mistaken?

--Leo--
___
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] how to maintain a set of patches?

[Eric]

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 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 of
> repositories.

"have to"? Why? Is this a case of having to step back and look at the aim
of the workflow rather than assuming that it is set in stone?

> (1) PRV.fossil -- is my private repo where all my dirty laundry is stored

Do you need a repository for this? A repository is not a backup tool.

> (2) TEAM.fossil -- this is a place shared by the development team.
> Mistakes can be annotated as "mistake" and backed out as you said.

> (3) PUBLIC.fossil -- is a clean and shiny final result that must be
> devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos.

Why do you need (3)? Who are you hiding stuff from? I think a clean branch
is all you need.

Actually I think most of your issues can be dealt with by suitable use of
branches. To go back to your earlier example, if P2 has nothing to do with
P1 it should probably have been in a branch of its own.

Which reminds me that I was going to say earlier that I don't understand
the emphasis on patches. A patch is just a way of transforming one version
of a file into another version, and is not a necessary component of an SCM
system.

Eric

-- 
ms fnd in a lbry

___
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] how to maintain a set of patches?

[Leo Razoumov]

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* asking for a "git rebase" equivalent.

But I have to follow a work-flow that consists of a cascade of repositories.

(1) PRV.fossil -- is my private repo where all my dirty laundry is stored
(2) TEAM.fossil -- this is a place shared by the development team.
Mistakes can be annotated as "mistake" and backed out as you said.
(3) PUBLIC.fossil -- is a clean and shiny final result that must be
devoid of all the crazy stuff from TEAM.fossil and PRV.fossil repos.

So far I found no way to accomodate (1)->(2)->(3) cascading work-flow.
Please, advice if I am missing something (I am a novice fossil user).
Previous discussions on this list suggested a new feature [1] that
would allow to push/pull individual leaves or branches.
If implemented it would resolve my biggest grievance with fossil.

[1]  http://code.linuxfood.net/pub/repo/fossil-limsync

--Leo--
___
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] how to maintain a set of patches?

[Richard Hipp]

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 used to be) done.  You write in
ink.  If an error is found, you annotate the erroneous entry with a note of
correction and/or create new entries to undo the mistake.  You do not erase
or alter existing entries.  And in this way one maintains an audit trail.

Other VCSes allow you to edit the DAG.  (The rebase command of git is the
prime example.)  That's OK for git because their philosophy is that the DAG
is part of the project documentation and should be clean and neat.  The
Fossil philosophy, in contrast, is that the DAG should be a true and
accurate history what you really did, rather than what you should have
done.

So the git-way of handling a mistaken commit would be to roll it back.  The
Fossil-way would be to tag that commit as being the beginning of a new
branch, typically a branch named "mistake", and then close the branch.
You can see examples of the Fossil-way, here:

   http://www.fossil-scm.org/fossil/timeline?c=2011-06-16+18%3A10%3A54&n=6
   http://www.sqlite.org/src/timeline?r=mistake

That said, I'm not completely opposed to having the ability to back out a
mistaken commit, so long as that commit has not been pushed or synced to
other repositories.  It is DAG editing (rewriting history) that I am
opposed to.  Rewriting history (rebase) and omitting parts of history
(rolling back commits) are distinct concepts, and rewriting (lying) is
clearly a greater sin than omitting irrelevancies.  But most Fossil users
operate in autocommit mode, meaning that commit and push happen together,
so there is seldom exist any unsynced commits, which is perhaps the biggest
reason why rollback has never been implemented.

For contributing to Fossil itself, there is a Pre-checkin
Checklistthat
developers are suppose to follow prior to each 'fossil commit".  (A
similar checklist exists for SQLite.)  A key element of this checklist is
the "fossil diff" - to make sure you really know what you are about to
check in.  Very often I spot debugging statements that should have been
removed, missing or erroneous comments, bad indentation, or goofy variable
names during that "fossil diff" step, and thus have an opportunity to
correct those errors prior to making them a part of the permanent record.
I also find that I am able to write better checkin comments if I have just
reviewed all changes associated with the checkin.  I highly recommend that
you adopt some kind of short, simple pre-checkin checklist for your
projects as well, and that this checklist involve a "diff" of what is about
to be checked in.  It really does help.

-- 
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] how to maintain a set of patches?

[Leo Razoumov]

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 model has only two
>> choices: public branches that are accessible to all, and private
>> branches that are for-your-eyes-only.
>
> Afaik, it's possible to push private branches as well, but, I agree,
> Fossil is mostly 'all or nothing'.
>

Yes, you can push *all* private branches with "fossil push --private".
Again, it is all or nothing proposition. In my workflow I need to push
few select branches to a remote repo. For the most part I use private
branches as for-my-eyes-only throw away temporaries which are cleansed
with "fossil scrub".

Recently Brian Smith announced on this list that he is working on
limsync fossil extension that allows to push/pull individual branches.
http://code.linuxfood.net/pub/repo/fossil-limsync
The code is still experimental and has some issues but hopefully it
will stabilize soon.

--Leo--
___
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] how to maintain a set of patches?

[Gour]

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 years ago. Now I abandoned Hg completely and am
> an active GIT user for my heavy lifting projects. I recently
> discovered fossil and find it very refreshing and intriguing.

I simply cannot stand Git considering it's too complex as a DVCS tool
forcing one to think more about the the tool than I'm ready to do.

Maybe I'm just spoiled with Darcs. ;)

> 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 model has only two
> choices: public branches that are accessible to all, and private
> branches that are for-your-eyes-only. 

Afaik, it's possible to push private branches as well, but, I agree,
Fossil is mostly 'all or nothing'.

I'd like to be able to get rid (or as HG says 'close') of old
experimental branches whose patches are applied to the trunk without the
need to resort too many different hacks.

> But I need few branches that I share with my team members but do not
> leak outside of the company.  Fossil provides no mechanism to support
> such a work-flow.

Right. I'd like to have simple 'rollback' as well in a situation when I
quickly find out that the commit was simply mistake...


Sincerely,
Gour

-- 
Therefore, without being attached to the fruits of activities, 
one should act as a matter of duty, for by working without 
attachment one attains the Supreme.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Leo Razoumov]

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 "patch" method does not handle addition/removal
>> of the files.

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.

>
>> P.S. Maintaining patch sets, squashing/folding are everyday tasks in
>> many popular work-flows. It would be great if fossil supports them
>> natively rather that via ugly hacks.
>
> I fully agree with it. ;)
>
> Btw, may I ask you do you miss something else in Fossil as (possibly)
> ex-hg user?
>

I used Hg briefly few years ago. Now I abandoned Hg completely and am
an active GIT user for my heavy lifting projects. I recently
discovered fossil and find it very refreshing and intriguing.

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 model has only two
choices: public branches that are accessible to all, and private
branches that are for-your-eyes-only. But I need few branches that I
share with my team members but do not leak outside of the company.
Fossil provides no mechanism to support such a work-flow.

--Leo--
___
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] how to maintain a set of patches?

[Gour]

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
> fossil commit --tag P1-P3.squashed

I should produce better test case, but it could kind of work...although
it's not very pretty.

The point is that both hg & git have 'staging area' (fomer in the form
of MQ), so when one does with the patches, can cleanly apply them and
get rid of the patch queue.

Otoh, Fossil is, by design, quite 'unforgiving' when it comes to putting
mistakes 'under the rug'.

Maybe, for the above example it would be better to toss patches by using
stashes, but I've to experiment with it if it could provide better
workflow.

> 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 "patch" method does not handle addition/removal
> of the files.

Yeah, that's not pretty and I'd like to leave such job to Fossil itself.

> P.S. Maintaining patch sets, squashing/folding are everyday tasks in
> many popular work-flows. It would be great if fossil supports them
> natively rather that via ugly hacks.

I fully agree with it. ;)

Btw, may I ask you do you miss something else in Fossil as (possibly)
ex-hg user?

New Mercurial has brought interesting concepts of phases...still, I have
to experiment a bit more (again) with Fossil before deciding that to use
for our upcoming open-source project which we might tackle soon.

Iirc, there was statement by Richard that he made 'rename' workable, but
too cumbersome, but I see that Fossil now has 'rename' again. What has
happened?


Sincerely,
Gour


-- 
What is night for all beings is the time of awakening 
for the self-controlled; and the time of awakening for 
all beings is night for the introspective sage.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Leo Razoumov]

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 therefore potential
> contributors although experts in the field are probably not savvy with
> DVCS tools, so Fossil is definitely unprecedented wiht its features and
> simplicity to setup & use.
>
> Otoh, we're familiar with DVCS tools (starting from darcs, bzr, mtn) and
> now being hg user would like to not to lose any functionality from e.g.
> hg. My question is connected with Mercurial's MQ feature...
>
>> Then after some time trunk moves forward
>>
>> ABCDE--   <= trunk
>>       \-P1--P2--P3   <= my-patches
>
> Let's assume I've the same situation like above, but consider that my
> patches are too granular to commit each one to the trunk and would like
> to eg. combine P1 & P3 together and then apply them as:
>
> P2' --> P1_P3' to my trunk.
>
> Is it possible to do it in Fossil?
>

In git --rebase it is known as patch squashing.

Could you, try the following (untested)

fossil update E
fossil merge --cherrypick P1
fossil merge --cherrypick P2
fossil merge --cherrypick P3
fossil commit --tag P1-P3.squashed

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 "patch" method does not handle addition/removal
of the files.

--Leo--

P.S. Maintaining patch sets, squashing/folding are everyday tasks in
many popular work-flows. It would be great if fossil supports them
natively rather that via ugly hacks.
___
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] how to maintain a set of patches?

[Gour]

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 field are probably not savvy with
DVCS tools, so Fossil is definitely unprecedented wiht its features and
simplicity to setup & use.

Otoh, we're familiar with DVCS tools (starting from darcs, bzr, mtn) and
now being hg user would like to not to lose any functionality from e.g.
hg. My question is connected with Mercurial's MQ feature...

> Then after some time trunk moves forward
> 
> ABCDE--   <= trunk
>   \-P1--P2--P3   <= my-patches

Let's assume I've the same situation like above, but consider that my
patches are too granular to commit each one to the trunk and would like
to eg. combine P1 & P3 together and then apply them as:

P2' --> P1_P3' to my trunk.

Is it possible to do it in Fossil?

Mercurial's MQ offers qfold command, and here is the help file for it:

[gour@atmarama gour] hg help qfold
hg qfold [-e] [-k] [-m TEXT] [-l FILE] PATCH...

fold the named patches into the current patch

Patches must not yet be applied. Each patch will be successively applied
to the current patch in the order given. If all the patches apply
successfully, the current patch will be refreshed with the new cumulative
patch, and the folded patches will be deleted. With -k/--keep, the folded
patch files will not be removed afterwards.

The header for each folded patch will be concatenated with the current
patch header, separated by a line of "* * *".

Returns 0 on success.

options:

 -e --edit edit patch header
 -k --keep keep folded patch files
 -m --message TEXT use text as commit message
 -l --logfile FILE read commit message from file

use "hg -v help qfold" to show more info



Sincerely,
Gour


-- 
There are principles to regulate attachment and aversion pertaining to 
the senses and their objects. One should not come under the control of 
such attachment and aversion, because they are stumbling blocks on the 
path of self-realization.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature
___
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] how to maintain a set of patches?

[Leo Razoumov]

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.  The latest trunk version of fossil does
> this.  http://www.fossil-scm.org/fossil/ci/9c28bca430?sbs=1
>

Wow! That was fast (under 2 hours for a feature)!!

Thanks,
--Leo--
___
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] how to maintain a set of patches?

[Richard Hipp]

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-scm.org/fossil/ci/9c28bca430?sbs=1


-- 
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] how to maintain a set of patches?

[Leo Razoumov]

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
>> > fossil commit --tag P2p
>> > fossil merge --cherrypick P3
>> > fossil commit --tag P3p
>> >
>>
>> Richard,
>> thanks for the suggestion. Will I have to manually provide commit
>> messages for each commit?
>
>
> Yes.  And you'll need to manually resolve any merge conflicts that come up
> to.

I agree about merge conflicts. But as far as commit messages are
concerned 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.

--Leo--
___
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] how to maintain a set of patches?

[Richard Hipp]

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
> > fossil commit --tag P3p
> >
>
> Richard,
> thanks for the suggestion. Will I have to manually provide commit
> messages for each commit?
>

Yes.  And you'll need to manually resolve any merge conflicts that come up
to.


>
> --Leo--
>



-- 
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] how to maintain a set of patches?

[Leo Razoumov]

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 manually provide commit
messages for each commit?

--Leo--
___
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] how to maintain a set of patches?

[Richard Hipp]

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 set of patches on a
> >> branch which are periodically reapplied as trunk moves forward.
> >
> > If you apply a patch once, it is on that branch.  To "reapply" a patch
> would
> > be a no-op, since the changes are already present on the branch, unless
> for
> > some reason you had backed the patch out since the prior application.
> > Perhaps I don't understand what you are asking for?
> >
>
> I am sorry if my language was not clear. Here are the diagrams:
>
> I start "my-patches" branch from trunk commit B and organize my
> changes as a set of patches
> each one addressing specific issue.
>
> AB--   <= trunk
>  \-P1--P2--P3  <= my-patches
>
> Then after some time trunk moves forward
>
> ABCDE--   <= trunk
>  \-P1--P2--P3   <= my-patches
>
> Now I want to reapply (I am avoiding word "rebase") my patches P1 through
> P3
> to the trunk commit E to achieve something like this
>
> /-P1'--P2'--P3' <= my-patches
> ABCDE--   <= trunk
>  \-P1--P2--P3 <= closed
>
> I am effectively rebasing my patches to the new trunk commit and I
> will close the leaf on the old branch.
>
> If I use merge then all three patches will be squashed into a single
> change-set. I would rather prefer to keep them as individual patches.
>

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





>
> --Leo--
>



-- 
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] how to maintain a set of patches?

[Leo Razoumov]

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 trunk moves forward.
>
> If you apply a patch once, it is on that branch.  To "reapply" a patch would
> be a no-op, since the changes are already present on the branch, unless for
> some reason you had backed the patch out since the prior application.
> Perhaps I don't understand what you are asking for?
>

I am sorry if my language was not clear. Here are the diagrams:

I start "my-patches" branch from trunk commit B and organize my
changes as a set of patches
each one addressing specific issue.

AB--   <= trunk
  \-P1--P2--P3  <= my-patches

Then after some time trunk moves forward

ABCDE--   <= trunk
  \-P1--P2--P3   <= my-patches

Now I want to reapply (I am avoiding word "rebase") my patches P1 through P3
to the trunk commit E to achieve something like this

 /-P1'--P2'--P3' <= my-patches
ABCDE--   <= trunk
  \-P1--P2--P3 <= closed

I am effectively rebasing my patches to the new trunk commit and I
will close the leaf on the old branch.

If I use merge then all three patches will be squashed into a single
change-set. I would rather prefer to keep them as individual patches.

--Leo--
___
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] how to maintain a set of patches?

[Richard Hipp]

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 that branch.  To "reapply" a patch
would be a no-op, since the changes are already present on the branch,
unless for some reason you had backed the patch out since the prior
application.

Perhaps I don't understand what you are asking for?



> Git
> has "git rebase", Mercurial has "hg mq". What solution does fossil
> offer?
>
> --Leo--
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
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

[fossil-users] how to maintain a set of patches?

[Leo Razoumov]

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--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users