Re: [fossil-users] Merge - including files from other branches - best practice?

[j. van den hoff]

On Fri, 17 Apr 2015 06:56:13 +0200, Andy Bradford  
 wrote:



Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600:


Partly I think it is because your  test case consists of a single file
of a  single line, which  means probably  (I would think)  every merge
resulted in a conflict that you had to resolve manually.


Yes, every  merge is a conflict  which I resolve arbitrarily  by leaving
just one of the conflicting changes.


Effectively, the  line from  newbranch was deleted  and the  line from
trunk was inserted, so  by the time of the merge  there is nothing new
or changed in newbranch to merge into trunk.


That's effectively what  seems to be happening. Even  though ``file'' is
different on newbranch, when I merge  it into trunk, it doesn't consider
the contents of ``file'' as  being in conflict---which surprised me. All
other merges  resulted in conflict resolution  that had to happen.  So I
was expecting  conflict resolution when  I merged in  the branch---there
was none.

I'm still a  bit confused why it  didn't think there was  a conflict and
just chose instead to take the content from trunk (which is why it shows
no differences).


+1: I, too, don't really get it, why a file deletion should be treated  
differently from edits to the file (including the case where an empty file  
would be the result). at merge time, all conflicting differences between  
both branches should be reported and would nee manual resolution. so if  
`foo' had been deleted in the past on trunk and later a new file of that  
name is created on the branch, it would seem correct to handle this as a  
conflict just as if `foo' still where in existence on trunk whereas if  
`foo' never has existed on trunk in the first place, the new file from the  
branch should simply be merged as a non-conflicting difference. what am I  
missing?




Thanks for your response.

Andy



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] terminology confusion

[j. van den hoff]

On Thu, 16 Apr 2015 22:58:55 +0200, Ron W  wrote:


On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison 
wrote:


Some thoughts:

More seriously, the Wikipedia article on forking is probably worth a  
read:

http://en.wikipedia.org/wiki/Fork_(software_development)

I would claim that github is the odd man out here, having appropriated a
term that historically meant something undesirable and changing it into  
an

intended desirable part of the software development process.



Certainly, Github's use of "fork" is different that saying "Devuan" is a
fork of "Debian".

As to whether a fork is undesirable depends on point of view. I am
willfully ignorant regarding the Debian people's opinions of Devuan. I
will, however, admit that I think the Inkscape fork of Sodapodi benefited
me,



Accidental head or accidental branch don't seem to apply if for no other
reason a fork *can* be deliberate. That's not the norm but --allow-fork
does exist as an option for those cases when fossil can detect a fork  
will

happen but to allow it anyway. I suspect most people don't type
--allow-fork accidentally (when they type it at all). :)



In my experience, a "fork" results when I or one of my teammates forgets  
to

start a new branch. So, from our perspective, "accidental" is very
applicable. Even with "fossil forks", such an undistinguished "branch"
would be easy to loose track of. I would not want to create a "fork".


So, if we *must* have a unique term, I'd vote for twig as I've never  
heard
it used in a dvcs context and can't find such a reference via Google.  
Mind
you, if we started using twig there is nothing to stop github (or  
others)

from coming along and appropriating the terminology, so we could wind up
right back in this position seven years down the road.



I'm not saying _must_. I only want to point out that it could be a
non-trivial obstacle to adoption for Fossil for some people.


personally, I don't see a problem with calling such random branches a fork  
within the fossil context. but I agree that the use/meaning is a bit  
idiosyncratic in view of the existence of 'project forks' and  
(unfortunately) github calling the project clone maintained on the server  
side a fork (I believe that's what it is, right?).


semantically, it might be stated that "fork" somewhat breaks the tree  
paradigm (trunk, branch, leave...) or at least introduces a topological  
property where otherwise "components" are used. so the suggestion to  
change to "twig" might really be a good thing. but if changing the  
terminology really is a seriously considered issue, than I cannot abstain  
from proposing "shoot" instead (which would open the theoretical  
possibility to indicate it as `SHOOT!' in the CLI timeline display --  
which most of the time, would be correct, too ;-)


but seriously: maybe all is good and well already ...


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] Merge - including files from other branches - best practice?

[Andy Bradford]

Thus said Scott Robison on Thu, 16 Apr 2015 21:00:50 -0600:

> Partly I think it is because your  test case consists of a single file
> of a  single line, which  means probably  (I would think)  every merge
> resulted in a conflict that you had to resolve manually.

Yes, every  merge is a conflict  which I resolve arbitrarily  by leaving
just one of the conflicting changes.

> Effectively, the  line from  newbranch was deleted  and the  line from
> trunk was inserted, so  by the time of the merge  there is nothing new
> or changed in newbranch to merge into trunk.

That's effectively what  seems to be happening. Even  though ``file'' is
different on newbranch, when I merge  it into trunk, it doesn't consider
the contents of ``file'' as  being in conflict---which surprised me. All
other merges  resulted in conflict resolution  that had to happen.  So I
was expecting  conflict resolution when  I merged in  the branch---there
was none.

I'm still a  bit confused why it  didn't think there was  a conflict and
just chose instead to take the content from trunk (which is why it shows
no differences).

Thanks for your response.

Andy
-- 
TAI64 timestamp: 400055309290


___
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] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Scott Robison]

On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich  wrote:

>  ‎I'd argue this is not intuitive, especially to a new Fossil user.
> "Losing" the file like this and not reporting at least as a warning seems
> like a wrong design choice, to me.
>

I'd agree it is not intuitive, as it took some hours of my time when I
thought I'd found a bug a month ago to trace through the code looking for a
flaw that didn't exist. I had told it at one point in time to merge in a
deletion into my branch, and so when it came time to play catch up to
trunk, it did what I had told it to do previously: Keep text previously
deleted out of the new merge, even though in this case I needed to readd
something due to other changes in fossil.


>  I actually like flagging the file as a conflict, with auto-resolution
> being to keep (re-add) the file. If this is tagged distinctively, then it
> is very easy - when you don't want the files re-introduced - to grep the
> output of 'fossil status' and bulk delete such files before committing the
> merge.
>

I can imagine a lot of people being annoyed if auto resolution was to add a
file previously deleted from a branch back to the branch. I can see that
being every bit as confusing to them as it not being re-added is to you.
Just as my deleted text a month ago was to me.


>  But at least a warning would be very useful. We already have warnings
> when files don't have common ancestors while merging (the cause of which
> confused me enough times and is probably related to this).
>

How about this scenario:

1. Trunk is the mainline branch from which releases are made.
2. Feature is a branch for ongoing development of some feature.
3. Periodically you merge trunk into feature so that you don't drift too
far (up to and including just before the final merge back to trunk).
4. In the end, you merge from the feature back to trunk when everything is
ready for release.

I think in this case you'd get the warning you seek because in the parent
branch it had been deleted while being edited in the child branch (the
nearest common ancestor was on trunk).

I think you're right about the common ancestor confusion. I certainly can
see the point about "deletion from one branch and edits in another branch
being arguably a conflict requiring resolution". I'm just can't think of a
better way to handle it than at present. This is probably why I don't get
paid the big bucks.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Steve Stefanovich]

‎I'd argue this is not intuitive, especially to a new Fossil user. "Losing" the 
file like this and not reporting at least as a warning seems like a wrong 
design choice, to me.

I actually like flagging the file as a conflict, with auto-resolution being to 
keep (re-add) the file. If this is tagged distinctively, then it is very easy - 
when you don't want the files re-introduced - to grep the output of 'fossil 
status' and bulk delete such files before committing the merge.

But at least a warning would be very useful. We already have warnings when 
files don't have common ancestors while merging (the cause of which confused me 
enough times and is probably related to this).

Richard, do you have a view on this?


From: Scott Robison
Sent: Friday, 17 April 2015 08:37
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Merge - including files from other branches - best 
practice?


On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich 
mailto:s...@stef.rs>> wrote:
‎I think what happened is that the file got deleted in the trunk (by another 
merge) and the OP expected it to be re-added by the last merge because the file 
was  there.

Is this by design? I would've expected it too.

It is by design. Merging isn't always intuitive, and certainly there could be a 
bug in it. I thought I'd found one a month or so ago but after debugging and 
going through the code with a fine toothed comb, I realized I was wrong. It was 
related to edits to the same file in the same place and it was not obviously 
why previously merges had made certainly lines of code "unavailable" in the 
merge conflict resolution.

Consider this (commits are assumed to happen at each stage):

1. Trunk commit includes file foo.
2. Branch is created from trunk (which includes foo).
3. Edits are made on branch.
4. Merged from branch to trunk (edits now reflected on trunk).
5. File is removed from trunk.
6. More edits are made on branch.
7. Merged from branch to trunk (there is no foo in trunk to which to apply the 
edits, and foo was not *added* to the branch).

Believe me, I understand, merging is not always intuitive if you don't have 
absolute complete awareness of the state of all files in both branches in every 
commit on each branch. In this case, the fact that the file was removed from 
trunk meant there was no where to put the edits from the branch.

The only other way of "resolving" this would be to give some sort of merge 
conflict that the edits from branch are to an empty file on trunk, but then one 
could argue "I deleted foo from trunk, don't waste my time with conflict 
resolution reports".

SDR

  Original Message
From: Warren Young
Sent: Friday, 17 April 2015 06:46
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Merge - including files from other branches -   
best practice?


On Apr 16, 2015, at 2:44 PM, Warren Young 
mailto:w...@etr-usa.com>> wrote:
>
> On Apr 16, 2015, at 10:47 AM, Johan Kuuse mailto:jo...@kuu.se>> 
> wrote:
>>
>> In c-stdin, I created the file b64.c
>
> That’s not what this says:

Also, notice that the checkin that claims to have created b64.c actually 
modifies the copy created on the trunk:

  http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
Scott Robison





___
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] Merge - including files from other branches - best practice?

[Scott Robison]

On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford 
wrote:

> Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600:
>
> > It is by design. Merging isn't always intuitive, and certainly there
> could
> > be a bug in it.
>
> Perhaps like this one:
>
> http://fossil.bradfords.org:8080/info/b1e9974a37c648fe
>
> Why was that merge essentially a no-op?
>

Partly I think it is because your test case consists of a single file of a
single line, which means probably (I would think) every merge resulted in a
conflict that you had to resolve manually. Here is what I think is
happening:

[1413f8301f] on trunk leads to
[793622de13] on newbranch leads to
[2b0c514af3] on newbranch
[ec781a493d] on trunk

At this point trunk is merged into newbranch resulting in [d228092800].
There had to have been a conflict and the merge was resolved as taking the
line from trunk, not newbranch.

At this point newbranch has a single file with a single line that came from
trunk. There are 5 more commits before [b1e9974a37] which merges newbranch
back into trunk, and since newbranch came from trunk during conflict
resolution, the nearest common ancestor came from trunk, so trunk wins.

Effectively, the line from newbranch was deleted and the line from trunk
was inserted, so by the time of the merge there is nothing new or changed
in newbranch to merge into trunk.

Note that I have not deconstructed and played back all these changes. I
have looked at all of the commits though and this is the best I think one
can expect a merge algorithm to do with the lines in question.

-- 
Scott Robison
___
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] Merge - including files from other branches - best practice?

[Andy Bradford]

Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600:

> It is by design. Merging isn't always intuitive, and certainly there could
> be a bug in it.

Perhaps like this one:

http://fossil.bradfords.org:8080/info/b1e9974a37c648fe

Why was that merge essentially a no-op?

I'm confused...

Thanks,

Andy
-- 
TAI64 timestamp: 400055306ce8


___
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] Two trunks?

[Andy Bradford]

Thus said Ron W on Thu, 16 Apr 2015 21:04:12 -0400:

> I disagree. While  it might be the most common  case, merging does not
> explicitly  state any  intent beyond  the  merge itself,  even a  full
> merge.

After one has merged a fork, does ``fossil merge'' report that there are
any more forks to be merged on  the branch? If not, then does not Fossil
intend that it is no longer a fork?

> After all, a merge doesn't automatically  close a named branch. So why
> would a merge automatically make a "fork" not a fork?

As I tried to point out earlier,  ``close'' is a special term in Fossil.
The only time  a branch is ``closed''  is if it has a  ``closed'' tag on
it. Merging  the branch  does not  ``close'' the branch.  It is  still a
branch because  new commits against its  leaf are still allowed.  If you
merge a  fork, commits against  it are no  longer allowed, at  least not
without another --allow-fork (or an accident).

Neither does merging a fork ``close'' the fork, but it is it no longer a
fork by virtue of the fact that  it has been merged into itself. To make
it a  fork again,  one would have  to commit against  the node  that was
merged.

One can have a fork on a non-trunk branch too:

http://fossil.bradfords.org:8080/timeline


> Closing it  or making it the  start of a new,  named branch explicitly
> indicate an intent to remove "fork" status.

Why does merging not removes ``fork'' status?

If it  hasn't changed  status, why  would ``fossil  merge'' cease  to to
think that there is a fork to merge. ``fossil help merge'' says:

``If the  VERSION argument is  omitted, then  Fossil attempts to  find a
recent fork on the current branch to merge.''

For Fossil to attempt to find a  recent fork, must it not have a working
definition of just what a fork is first?

Notice also  that Fossil does  not label a fork  that has been  merged a
leaf.

But a  branch that  has been merged  is still considered  a leaf  (or in
other words  an active named  fork) because  the ``closed'' tag  has not
been imposed  upon it.  Once ``closed''  the branch  will be  a ``closed
leaf.''

So clearly Fossil does treat a ``fork leaf'' differently from a ``branch
leaf.''

Oddly enough, I'm not sure if this is a bug... but if I update to:

http://fossil.bradfords.org:8080/info/ddbeee499bb3cee9

``fossil  update''  does  not   complaing  about  there  being  multiple
descendants. However, ``fossil merge'' actually does merge in the Closed
leaf that  is part of  the fork. Not sure  if this is  actually intended
behavior,  but  it does  seem  that  ``fossil  merge'' treats  the  fork
differently than ``fossil update'' does.

Thanks for the interesting discussion.  Definitely good to flesh out the
definitions we're using.

Thanks,

Andy
-- 
TAI64 timestamp: 400055306bbf


___
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] Fossil 2.1: Scaling

[Nico Williams]

On Mon, Mar 2, 2015 at 6:30 AM, Richard Hipp  wrote:
> Ben Pollack's essay at
> http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/
> succinctly points up some of the problems with DVCS versus centralized
> VCS (like subversion).  Much further discussion occurs on the various
> news aggregator sites.
>
> So I was thinking, could Fossil 2.0 be enhanced in ways to support
> scaling to the point where it works on really massive projects?
>
> The key idea would be to relax the requirement that each client load
> the entire history of the project.  Instead, a clone would only load a

git can do this, and it's a relatively new feature.  The really nice
thing would be to load whatever is needed on demand, or to perform
certain operations (e.g., producing annotated sources, viewing
history, ...) on the server.

> limited amount of history (a month, a year, perhaps even just the most
> recent check-in).  This would make cloning much faster and the
> resulting clone much smaller.  Missing content could be downloaded
> from the server on an as-needed basis.  So, for example, if the user
> does "fossil update trunk:2010-01-01" then the local client would
> first have to go back to the server to fetch content from 2010.  The
> additional content would be added to the local repository.  And so the
> repository would still grow.  But it grows only on an as-needed basis
> rather than starting out at full size.  And in the common case where
> the developer never needs to look at any content over a few months
> old, the growth is limited.
>
> By downloading the meta-data that is currently computed locally by
> "rebuild", many operations on older content, such as timelines or
> search, could be performed even without having the data present.  In
> the "bsd-src.fossil" repository, the content is 78% of the repository
> file and the meta-data is the other 22%.  So a clone that stored only
> the most recent content together with all metadata might be about
> 1/4th the size of a full clone.  For even greater savings, perhaps the
> metadata could be time-limited, though not as severely as the content.
> So perhaps the clone would only initialize to the last month of
> content and the last five years of metadata.
>
> For "wide" repositories (such as bsd-src) that hold many thousands of
> files in a single check-out, Fossil could be enhanced to allow
> cloning, checkout, and commit of just a small slice of the entire
> tree.  So, for example, a clone might hold just the bin/ subdirectory
> of bsd-src containing just 56 files, rather than all 147720 files of a
> complete check-out.  Fossil should be able to do everything it
> normally does with just this subset, including commit changes, except
> that on new manifests generated by the commit, the R-card would have
> to be omitted since the entire tree is necessary to compute the
> R-card.  But the R-card is optional already, controlled by the
> "repo-cksum" setting, which is turned off in bsd-src, so there would
> be no loss in functionality.

Yes, this would be very nice.  Though a BSD would probably need
significant build system rototilling to make it possible for
developers to work on isolated portions of the code with partial
clones only.

> The sync protocol would need to be greatly enhanced to support this
> functionality.  Also, the schema for the meta-data, which currently is
> an implementation detail, would need to become part of the interface.
> Exposing the meta-data as interface would have been unthinkable a few
> years ago, but at this point we have accumulated enough experience
> about what is needed in the meta-data to perhaps make exposing its
> design a reasonable alternative.

Exposing the metadata would be one of the best things Fossil could do,
IMO, once it's ready.

Nico
--
___
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 about renaming a fork to "fork-*"? (Was: Two trunks?)

[Steve Stefanovich]

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
mailto:amb-fos...@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove "fork" status.

___
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] Two trunks?

[Ron W]

On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
wrote:

> And a fork that ends in being merged is also no longer a fork.


I disagree. While it might be the most common case, merging does not
explicitly state any intent beyond the merge itself, even a full merge.
After all, a merge doesn't automatically close a named branch. So why would
a merge automatically make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly
indicate an intent to remove "fork" status.
___
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] Two trunks?

[Andy Bradford]

Thus said Matt Welland on Thu, 16 Apr 2015 15:55:47 -0700:

> I think merging  a fork resolves then  it and it is no  longer a fork.
> Only open forks represent potentially  orphaned changes. Maybe we need
> better terminology.

I think by  definition it must be considered no  longer a fork, however,
it may be a leaf if it is the tip of that branch of the fork.

Perhaps there is some confusion in the use of open/close with respect to
a fork?  ``Close'' does have a  specific meaning in Fossil  and there is
certainly not an explicit ``close'' tag on the node that has been merged
from a fork. Only if someone were  to commit against this node, it would
begin a new fork.

But a fork  that ends in a  leaf that is ``closed'' is  not considered a
fork. And a fork that ends in being merged is also no longer a fork.

Andy
-- 
TAI64 timestamp: 400055305312


___
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] Two trunks?

[Matt Welland]

On Thu, Apr 16, 2015 at 1:22 PM, Ron W  wrote:

> On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland 
> wrote:
>
>> Since these are effectively forks that have been resolved by merging is
>> it possible to detect them as such and not report them?
>>
>
> I think they probably could be reported as "merged forks", but I'm not
> sure that adds value. What if someone assumes that whomever merged the
> fork's content had simply forgotten to either close the fork or otherwise
> "resolve" it?
>

I think merging a fork resolves then it and it is no longer a fork. Only
open forks represent potentially orphaned changes. Maybe we need better
terminology. I don't call a merged fork a fork. The word "fork" implies
divergence to me (consistent with the usage in another thread about project
forks). If xemacs and emacs projects merge together they are no longer
forked. I suppose they were previously forked but if I'm an emacs
aficionado I don't care about a fork in the past that has been merged.

By my working definition of the word "fork" reporting a fork that was
merged back to the origin branch is a false error.


> Absent a comment or other explicit indicator of intent, any fork, merged
> or not, should be carefully reviewed and its status explicitly denoted.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
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] Merge - including files from other branches - best practice?

[Scott Robison]

On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich  wrote:

> ‎I think what happened is that the file got deleted in the trunk (by
> another merge) and the OP expected it to be re-added by the last merge
> because the file was  there.
>
> Is this by design? I would've expected it too.
>

It is by design. Merging isn't always intuitive, and certainly there could
be a bug in it. I thought I'd found one a month or so ago but after
debugging and going through the code with a fine toothed comb, I realized I
was wrong. It was related to edits to the same file in the same place and
it was not obviously why previously merges had made certainly lines of code
"unavailable" in the merge conflict resolution.

Consider this (commits are assumed to happen at each stage):

1. Trunk commit includes file foo.
2. Branch is created from trunk (which includes foo).
3. Edits are made on branch.
4. Merged from branch to trunk (edits now reflected on trunk).
5. File is removed from trunk.
6. More edits are made on branch.
7. Merged from branch to trunk (there is no foo in trunk to which to apply
the edits, and foo was not *added* to the branch).

Believe me, I understand, merging is not always intuitive if you don't have
absolute complete awareness of the state of all files in both branches in
every commit on each branch. In this case, the fact that the file was
removed from trunk meant there was no where to put the edits from the
branch.

The only other way of "resolving" this would be to give some sort of merge
conflict that the edits from branch are to an empty file on trunk, but then
one could argue "I deleted foo from trunk, don't waste my time with
conflict resolution reports".

SDR

  Original Message
> From: Warren Young
> Sent: Friday, 17 April 2015 06:46
> To: Fossil SCM user's discussion
> Reply To: Fossil SCM user's discussion
> Subject: Re: [fossil-users] Merge - including files from other branches -
>  best practice?
>
>
> On Apr 16, 2015, at 2:44 PM, Warren Young  wrote:
> >
> > On Apr 16, 2015, at 10:47 AM, Johan Kuuse  wrote:
> >>
> >> In c-stdin, I created the file b64.c
> >
> > That’s not what this says:
>
> Also, notice that the checkin that claims to have created b64.c actually
> modifies the copy created on the trunk:
>
>
> http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Scott Robison
___
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] Merge - including files from other branches - best practice?

[Steve Stefanovich]

‎I think what happened is that the file got deleted in the trunk (by another 
merge) and the OP expected it to be re-added by the last merge because the file 
was  there.

Is this by design? I would've expected it too.

  Original Message
From: Warren Young
Sent: Friday, 17 April 2015 06:46
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Merge - including files from other branches -   
best practice?


On Apr 16, 2015, at 2:44 PM, Warren Young  wrote:
>
> On Apr 16, 2015, at 10:47 AM, Johan Kuuse  wrote:
>>
>> In c-stdin, I created the file b64.c
>
> That’s not what this says:

Also, notice that the checkin that claims to have created b64.c actually 
modifies the copy created on the trunk:

  http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
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] terminology confusion

[Scott Robison]

On Thu, Apr 16, 2015 at 2:58 PM, Ron W  wrote:

> On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison 
> wrote:
>>
>> Some thoughts:
>>
>> More seriously, the Wikipedia article on forking is probably worth a
>> read: http://en.wikipedia.org/wiki/Fork_(software_development)
>>
>> I would claim that github is the odd man out here, having appropriated a
>> term that historically meant something undesirable and changing it into an
>> intended desirable part of the software development process.
>>
>
> Certainly, Github's use of "fork" is different that saying "Devuan" is a
> fork of "Debian".
>
> As to whether a fork is undesirable depends on point of view. I am
> willfully ignorant regarding the Debian people's opinions of Devuan. I
> will, however, admit that I think the Inkscape fork of Sodapodi benefited
> me,
>

I'd never heard of Devuan before today. I am familiar with the other
examples quoted from ESR:

"Forking is considered a Bad Thing—not merely because it implies a lot of
wasted effort in the future, but because forks tend to be accompanied by a
great deal of strife and acrimony between the successor groups over issues
of legitimacy, succession, and design direction. There is serious social
pressure against forking. As a result, major forks (such as the Gnu-Emacs
/XEmacs
 split, the fissioning of the386BSD
 group into three daughter projects,
and the short-lived GCC/EGCS split) are rare enough that they are
remembered individually in hacker folklore."

It's not that no one benefits from a traditional project fork. Someone must
or no one would ever go to the effort. But they often come at a high price
in hours spent keeping up with the other project, or incompatible drift
between two projects which is potentially hard on the community. Even
though there are benefits to the "project fork" there are also undesirable
side effects. Pros & Cons.

In the case of the "branch fork" that fossil describes, the negative is the
time it takes to merge the two back into one branch, or to rename one of
the forks so that it becomes its own branch. Certainly learning about forks
as early as possible so that they can be addressed appropriately is
beneficial to a project. Maybe calling it a "branch fork" or "forked
branch" might be adequate terminology.


> Accidental head or accidental branch don't seem to apply if for no other
>> reason a fork *can* be deliberate. That's not the norm but --allow-fork
>> does exist as an option for those cases when fossil can detect a fork will
>> happen but to allow it anyway. I suspect most people don't type
>> --allow-fork accidentally (when they type it at all). :)
>>
>
> In my experience, a "fork" results when I or one of my teammates forgets
> to start a new branch. So, from our perspective, "accidental" is very
> applicable. Even with "fossil forks", such an undistinguished "branch"
> would be easy to loose track of. I would not want to create a "fork".
>

Agreed, a deliberate fork would likely be quite rare. I was only saying it
is possible so "accidental branch" is not perfectly descriptive.


> So, if we *must* have a unique term, I'd vote for twig as I've never heard
>> it used in a dvcs context and can't find such a reference via Google. Mind
>> you, if we started using twig there is nothing to stop github (or others)
>> from coming along and appropriating the terminology, so we could wind up
>> right back in this position seven years down the road.
>>
>
> I'm not saying _must_. I only want to point out that it could be a
> non-trivial obstacle to adoption for Fossil for some people.
>

Sorry, I should have included a smiley in there somewhere. While part of me
does like the idea of using twig as a term somewhere just because it's
amusing, I did mean it tongue in cheek.

I still think "fork" is the right term. Fossil's use of it predates the
later redefinition by github. The software development industry use of it
predates github. If anything, change displayed instances of "fork" to
"forked branch" or "fork [two leaves on the same branch]".

In fact, as I think more about it, "forked branch" would be sufficiently
clear that it's not a github fork (a "forked project" if you will) while
alerting the person reading the text that something different from the
normal flow has occurred. Assuming they read it at all, anyway.

-- 
Scott Robison
___
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] terminology confusion

[Ron W]

On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison 
wrote:
>
> Some thoughts:
>
> More seriously, the Wikipedia article on forking is probably worth a read:
> http://en.wikipedia.org/wiki/Fork_(software_development)
>
> I would claim that github is the odd man out here, having appropriated a
> term that historically meant something undesirable and changing it into an
> intended desirable part of the software development process.
>

Certainly, Github's use of "fork" is different that saying "Devuan" is a
fork of "Debian".

As to whether a fork is undesirable depends on point of view. I am
willfully ignorant regarding the Debian people's opinions of Devuan. I
will, however, admit that I think the Inkscape fork of Sodapodi benefited
me,


> Accidental head or accidental branch don't seem to apply if for no other
> reason a fork *can* be deliberate. That's not the norm but --allow-fork
> does exist as an option for those cases when fossil can detect a fork will
> happen but to allow it anyway. I suspect most people don't type
> --allow-fork accidentally (when they type it at all). :)
>

In my experience, a "fork" results when I or one of my teammates forgets to
start a new branch. So, from our perspective, "accidental" is very
applicable. Even with "fossil forks", such an undistinguished "branch"
would be easy to loose track of. I would not want to create a "fork".


> So, if we *must* have a unique term, I'd vote for twig as I've never heard
> it used in a dvcs context and can't find such a reference via Google. Mind
> you, if we started using twig there is nothing to stop github (or others)
> from coming along and appropriating the terminology, so we could wind up
> right back in this position seven years down the road.
>

I'm not saying _must_. I only want to point out that it could be a
non-trivial obstacle to adoption for Fossil for some people.
___
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] terminology confusion

[Andy Bradford]

Thus said Ron W on Thu, 16 Apr 2015 15:27:38 -0400:

> So I don't know of an alternative  term already in use to suggest. Not
> can I think of any other alternative term to suggest.

I don't  know of an  alternative either; perhaps a  duplicate descendant
line.

Fossil simply defines it:

Having more than one leaf in the check-in DAG is called a "fork."

I've  often thought  Git's ``fork''  to  be used  incorrectly when  what
really happened was a clone, which is like a fork, but really, it's more
like a clone. :-)

Andy
--
TAI64 timestamp: 40005530218e
___
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] Merge - including files from other branches - best practice?

[Warren Young]

On Apr 16, 2015, at 2:44 PM, Warren Young  wrote:
> 
> On Apr 16, 2015, at 10:47 AM, Johan Kuuse  wrote:
>> 
>> In c-stdin, I created the file b64.c
> 
> That’s not what this says:

Also, notice that the checkin that claims to have created b64.c actually 
modifies the copy created on the trunk:

  http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070
___
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] Merge - including files from other branches - best practice?

[Warren Young]

On Apr 16, 2015, at 10:47 AM, Johan Kuuse  wrote:
> 
> In c-stdin, I created the file b64.c

That’s not what this says:

  http://kuu.se/fossil/b64.cgi/finfo?name=b64.c

I’ve done what you claim to have attempted, and if you had actually done this, 
you would have seen something like ADDED_BY_MERGE in the commit message 
commentary when you gave the “fossil merge” command.
___
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] terminology confusion

[Scott Robison]

On Thu, Apr 16, 2015 at 1:27 PM, Ron W  wrote:

> On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford 
> wrote:
>
>> This document contains what Fossil considers a fork:
>>
>> https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki
>
>
> Yes. And the _connotation_ of the term "fork" within the Fossil community
> is unintended/accidental commit to a parent commit with other child commits.
>
> My point is that Fossil uses the term "fork" differently from many other
> many other open source projects. Examples: "Devuan" is a fork of Debian,
> "Inkscape" is a fork of "Sodapodi", etc. Or, how Github uses it to mean a
> "contributor's clone".
>

Some thoughts:

If a unique term is required, how about calling an undesirable branch a
twig. ;)

More seriously, the Wikipedia article on forking is probably worth a read:
http://en.wikipedia.org/wiki/Fork_(software_development)

I would claim that github is the odd man out here, having appropriated a
term that historically meant something undesirable and changing it into an
intended desirable part of the software development process.  Mind you,
forking in a github sense doesn't have to mean "project branch with future
pull requests" though obviously that's how they intend it. A github fork is
really just a heavyweight branch, and until github was launched in 2008
(assuming their fork functionality was an original concept introduced at
launch) no one in the world used "fork" in this sense. Looking at the list
of DVCS projects on Wikipedia, it means every "notable" DVCS was introduced
prior to that usage (except for Veracity, which is apparently / arguably
dead anyway). I don't think github's success devolves on anyone else to
change their terminology any more than I think git's success means that
everyone should adopt their confusing hodge podge mass of commands &
options. In fact, from this point of view, github redefining terminology is
unsurprising given how I feel about git's use of terminology in places.

Given the traditional meaning of fork (an undesirable branch of development
that, if allowed to remain, limits future development options in some way),
I don't see that there is a real problem continuing to use the term fork.
Introducing a new non-obvious term just so there is distinct separation
between "fossil forks" and "github forks" seems to only complicate the
understanding of fossil.

Note that "undesirable branch of development" could apply to how fossil
uses fork, or how github might use fork in the case that the original
project never pulls anything back so the two projects diverge, or how BSDs
or emacs/xemacs forked deliberately.

Accidental head or accidental branch don't seem to apply if for no other
reason a fork *can* be deliberate. That's not the norm but --allow-fork
does exist as an option for those cases when fossil can detect a fork will
happen but to allow it anyway. I suspect most people don't type
--allow-fork accidentally (when they type it at all). :)

So, if we *must* have a unique term, I'd vote for twig as I've never heard
it used in a dvcs context and can't find such a reference via Google. Mind
you, if we started using twig there is nothing to stop github (or others)
from coming along and appropriating the terminology, so we could wind up
right back in this position seven years down the road.

Or we just continue to document what we mean when we use the term fork
(perhaps providing the extra text "two leaves on the same branch" or some
such when a fork warning is generated) and continue to provide the existing
tools to merge or rename.

-- 
Scott Robison
___
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] Two trunks?

[Ron W]

On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland 
wrote:

> Since these are effectively forks that have been resolved by merging is it
> possible to detect them as such and not report them?
>

I think they probably could be reported as "merged forks", but I'm not sure
that adds value. What if someone assumes that whomever merged the fork's
content had simply forgotten to either close the fork or otherwise
"resolve" it?

Absent a comment or other explicit indicator of intent, any fork, merged or
not, should be carefully reviewed and its status explicitly denoted.
___
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] Two trunks?

[Ron W]

On Thu, Apr 16, 2015 at 3:57 PM, Matt Welland 
wrote:

>
>
> On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans 
> wrote:
>
>> 2015-04-16 13:44 GMT+02:00 Matt Welland :
>> > I'm confused by this. If the fork was merged to trunk it is no longer a
>> fork
>> > and should not be detected. Can you elaborate?
>>
>> In fossil it is possible to merge a branch to trunk, but leave the
>> branch open. It could have been a partial merge, fossil has no way
>> to know that, until the user explicitly closes the branch. Therefore,
>> such a branch needs to be included in the fork-detection.
>>
>
> Since these are effectively forks that have been resolved by merging is it
> possible to detect them as such and not report them?
>
>
>>
>> Down to two:
>> $ fossil forks --bybranch
>> *** dg-misc ***
>>(1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
>> dg tags: dg-misc)
>>(2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
>> dg tags: dg-misc)
>> *** side-by-side-edit ***
>>(3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
>> the text area small so it will always fit in the column.
>>After page loaded enlarge the text area with Javascript. But
>> leave a little room (40px) as a margin between the two
>>columns. This insurers that side by side always succeeds.
>> (user: renez tags: side-by-side-edit)
>>(4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
>> changes so that the branches can be more easily compared.
>>(user: drh tags: side-by-side-edit)
>>
>> Analysing those last two, it's not difficult to see what happened:
>> 
>> > >
>>
>> The oldest commits were nothing more than merging trunk changes into
>> the branch. But later the user forgot about that (without seeing the
>> warning). So it's safe to assume that the older of the two commits
>> will not be continued upon, and can be closed. Done now.
>>
>> The fossil self-hosting repository is fork-free now (FWIW) !
>> Anyway, we still can test the fork-detection on SQLite ;-)
>> $ fossil forks --bybranch
>> *** branch-3.7.16 ***
>>(1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
>> drh tags: release, version-3.7.16.2, branch-3.7.16)
>>(2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
>> tester to the last released version. (user: mistachkin
>>tags: branch-3.7.16)
>> *** mistake ***
>>(3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
>> REINDEX and VACUUM statements by taking better advantage of
>>the fact that index keys are being inserted into b-trees in
>> sorted order. (user: dan tags: mistake)
>>(4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
>> this commit contains a typo causing a test to fail.
>>Was: Add an extra test to further verify that the FTS
>> notindexed option is working properly. (user: dan tags: mistake)
>>
>>
>> Hope this helps,
>> Jan Nijtmans
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
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] Two trunks?

[Matt Welland]

On Thu, Apr 16, 2015 at 5:37 AM, Jan Nijtmans 
wrote:

> 2015-04-16 13:44 GMT+02:00 Matt Welland :
> > I'm confused by this. If the fork was merged to trunk it is no longer a
> fork
> > and should not be detected. Can you elaborate?
>
> In fossil it is possible to merge a branch to trunk, but leave the
> branch open. It could have been a partial merge, fossil has no way
> to know that, until the user explicitly closes the branch. Therefore,
> such a branch needs to be included in the fork-detection.
>

Since these are effectively forks that have been resolved by merging is it
possible to detect them as such and not report them?


>
> Down to two:
> $ fossil forks --bybranch
> *** dg-misc ***
>(1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
> dg tags: dg-misc)
>(2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
> dg tags: dg-misc)
> *** side-by-side-edit ***
>(3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
> the text area small so it will always fit in the column.
>After page loaded enlarge the text area with Javascript. But
> leave a little room (40px) as a margin between the two
>columns. This insurers that side by side always succeeds.
> (user: renez tags: side-by-side-edit)
>(4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
> changes so that the branches can be more easily compared.
>(user: drh tags: side-by-side-edit)
>
> Analysing those last two, it's not difficult to see what happened:
> 
> 
>
> The oldest commits were nothing more than merging trunk changes into
> the branch. But later the user forgot about that (without seeing the
> warning). So it's safe to assume that the older of the two commits
> will not be continued upon, and can be closed. Done now.
>
> The fossil self-hosting repository is fork-free now (FWIW) !
> Anyway, we still can test the fork-detection on SQLite ;-)
> $ fossil forks --bybranch
> *** branch-3.7.16 ***
>(1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
> drh tags: release, version-3.7.16.2, branch-3.7.16)
>(2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
> tester to the last released version. (user: mistachkin
>tags: branch-3.7.16)
> *** mistake ***
>(3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
> REINDEX and VACUUM statements by taking better advantage of
>the fact that index keys are being inserted into b-trees in
> sorted order. (user: dan tags: mistake)
>(4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
> this commit contains a typo causing a test to fail.
>Was: Add an extra test to further verify that the FTS
> notindexed option is working properly. (user: dan tags: mistake)
>
>
> Hope this helps,
> Jan Nijtmans
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] terminology confusion

[Ron W]

On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford 
wrote:

> This document contains what Fossil considers a fork:
>
> https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki


Yes. And the _connotation_ of the term "fork" within the Fossil community
is unintended/accidental commit to a parent commit with other child commits.

My point is that Fossil uses the term "fork" differently from many other
many other open source projects. Examples: "Devuan" is a fork of Debian,
"Inkscape" is a fork of "Sodapodi", etc. Or, how Github uses it to mean a
"contributor's clone".

Unfortunately, other DVCs don't seem to have a name for these accidental
commits/branches, other than, for example (in Hg), "accidental head".

So I don't know of an alternative term already in use to suggest. Not can I
think of any other alternative term to suggest.
___
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] Two trunks?

[Andy Bradford]

Thus said Jan Nijtmans on Thu, 16 Apr 2015 10:38:17 +0200:

> There's a "fossil forks" command on trunk now:

Thank you. Looks great.

Oops...

$ ./fossil new /tmp/new.fossil > /dev/null
$ ./fossil forks -R /tmp/new.fossil  
SQLITE_ERROR: no such table: vmerge
./fossil: no such table: vmerge
SELECT leaf.rid  FROM leaf, event WHERE leaf.rid=event.objid   AND leaf.rid!=1  
 AND leaf.rid NOT IN (SELECT merge FROM vmerge)   AND NOT EXISTS(SELECT 1 FROM 
tagxref WHERE rid=leaf.rid   AND tagid=9   AND tagtype>0)   AND 
(SELECT value FROM tagxref   WHERE tagid=8 AND rid=1 AND tagtype>0) = (SELECT 
value FROM tagxref   WHERE tagid=8 AND rid=leaf.rid AND tagtype>0) ORDER BY 
event.mtime DESC LIMIT 1

I made changes to handle this in sync-forkwarn branch.

Maybe should have a vote on sync-forkwarn?

Thanks,

Andy
--
TAI64 timestamp: 400055300619
___
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] terminology confusion

[Andy Bradford]

Thus said Ron W on Thu, 16 Apr 2015 12:49:43 -0400:

> Unfortunately, I had  no luck finding any better term  for what Fossil
> calls a "fork". (My search-fu maybe off this morning.)

This document contains what Fossil considers a fork:

https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

Scroll to the Forking Versus Branching header.

Thanks,

Andy
--
TAI64 timestamp: 400055300276
___
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] Error synchronizing private check-ins

[Tokujo Echsula]

Here's an easy way to reproduce it:

fossil new 1.fossil
fossil open 1.fossil
echo > a.file
fossil addremove
fossil commit -m "private" --private
fossil clone 1.fossil 2.fossil
fossil pull -R 2.fossil --private

On Wed, Apr 15, 2015 at 6:26 PM, Mikhail Kryshen 
wrote:

> The problem reproduces with fossil built from the current trunk (abef6cf7).
>
> Mikhail Kryshen  writes:
>
> > Hello,
> >
> > I encountered a problem trying to transfer private check-ins between
> > personal clones of a repository:
> >
> > $ fossil pull --private --once ssh://host/fossils/project.fossil
> > Round-trips: 2   Artifacts sent: 0  received: 0
> > SQLITE_CONSTRAINT: abort at 8 in [INSERT INTO private VALUES(10049)]:
> UNIQUE constraint failed: private.rid
> > fossil: UNIQUE constraint failed: private.rid: {INSERT INTO private
> VALUES(10049)}
> >
> > This also happens with a newly created repository: сreate a repo
> > (test.fossil), open it, add a file, commit, make changes, commit
> > with --private, then
> >
> > $ fossil clone test.fossil test-clone.fossil
> > ... (no errors)
> >
> > $ fossil pull --private test.fossil -R test-clone.fossil
> > Round-trips: 2   Artifacts sent: 0  received: 0
> > SQLITE_CONSTRAINT: abort at 8 in [INSERT INTO private VALUES(6)]: UNIQUE
> constraint failed: private.rid
> > fossil: UNIQUE constraint failed: private.rid: {INSERT INTO private
> VALUES(6)}
> >
> > $ fossil push --private test-clone.fossil -R test.fossil
> > Round-trips: 2   Artifacts sent: 6  received: 0
> > Error: Database error: UNIQUE constraint failed: private.rid: {INSERT
> INTO private VALUES(6)}
> > Round-trips: 2   Artifacts sent: 6  received: 0
> > Push done, sent: 1283  received: 669  ip:
> >
> > $ fossil sync --private test-clone.fossil -R test.fossil
> > Round-trips: 2   Artifacts sent: 2  received: 0
> > Error: Database error: UNIQUE constraint failed: private.rid: {INSERT
> INTO private VALUES(6)}
> > Round-trips: 2   Artifacts sent: 2  received: 0
> > Sync done, sent:   received: 804  ip:
> >
> > $ fossil version
> > This is fossil version 1.32 [6c40678e91] 2015-03-14 13:20:34 UTC
>
> --
> Mikhail
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
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] terminology confusion

[Ron W]

On Thu, Apr 16, 2015 at 1:30 PM, James Moger  wrote:

> Mercurial would call a Fossil fork a "head"[1].
>
> -J
>
> [1]: http://mercurial.selenic.com/wiki/MultipleHeads
>

That would be what Fossil calls a "Leaf". I suppose, one could argue that,
in Fossil, a "fork" is a special case of a "leaf", but I consider it to be
an accidental, unnamed branch (allowing for the possibility of descendants
of the original "fork" commit).

So, in absence of an alternative, in Mercuial, a "fork" would be an
"accidental head" or "accidental branch".
___
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] terminology confusion

[James Moger]

Mercurial would call a Fossil fork a "head"[1].

-J

[1]: http://mercurial.selenic.com/wiki/MultipleHeads


On Thu, Apr 16, 2015 at 12:49 PM, Ron W  wrote:

> As the flurry of discussion of "forks" starts to ebb, it occurred to me
> there is a conflict between how Fossil defines "fork" and how many open
> source project define "fork".
>
> Fossil defines "fork" as an accidental, unintended "branch" in the commit
> history.
>
> But, to many in the open source community (and other SW development
> communities), a "fork" is an intentional split from the commit history to
> either create a development branch or to create a new project from an
> existing one. Example: Devuan Linux is a fork of Debian Linux (in contrast
> to Ubuntu, which is (was?) a down stream derivative of Debian).
>
> Also, there's the much older "fork in the road", referring a connected
> road going in a different direction.
>
> Unfortunately, I had no luck finding any better term for what Fossil calls
> a "fork". (My search-fu maybe off this morning.)
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] terminology confusion

[Ron W]

As the flurry of discussion of "forks" starts to ebb, it occurred to me
there is a conflict between how Fossil defines "fork" and how many open
source project define "fork".

Fossil defines "fork" as an accidental, unintended "branch" in the commit
history.

But, to many in the open source community (and other SW development
communities), a "fork" is an intentional split from the commit history to
either create a development branch or to create a new project from an
existing one. Example: Devuan Linux is a fork of Debian Linux (in contrast
to Ubuntu, which is (was?) a down stream derivative of Debian).

Also, there's the much older "fork in the road", referring a connected road
going in a different direction.

Unfortunately, I had no luck finding any better term for what Fossil calls
a "fork". (My search-fu maybe off this morning.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Merge - including files from other branches - best practice?

[Johan Kuuse]

Hi,

This is probably a trivial question, but I can't find a clear answer
in the documentation.
I have a repository at

http://kuu.se/fossil/b64.cgi/timeline

with two branches, trunk and c-stdin
In c-stdin, I created the file b64.c, which does not exist in trunk.
Some other files, created beforehand in trunk, were modified in c-stdin.
The changes in c-stdin were then merged into trunk, as seen in

http://kuu.se/fossil/b64.cgi/info/4e0d851bb88275cf056686c4c3e161bee84647ea

In this case, b64.c was not merged into trunk.
Of course I could have simply add an empty file named b64.c in trunk
before merging, but I don't think that is the way to do this
correctly.
In this case we are talking about one single file, which makes it easy
to do manually.
But what if there were thousands of files in each branch?
I am looking for an option similar to:

fossil update trunk
fossil merge c-stdin --include-missing-files

Sorry if I am missing something trivial in the documentation.
Any suggestions appreciated.

Regards,
Johan
___
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] Two trunks?

[Jan Nijtmans]

2015-04-16 13:44 GMT+02:00 Matt Welland :
> I'm confused by this. If the fork was merged to trunk it is no longer a fork
> and should not be detected. Can you elaborate?

In fossil it is possible to merge a branch to trunk, but leave the
branch open. It could have been a partial merge, fossil has no way
to know that, until the user explicitly closes the branch. Therefore,
such a branch needs to be included in the fork-detection.

Down to two:
$ fossil forks --bybranch
*** dg-misc ***
   (1) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
dg tags: dg-misc)
   (2) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
dg tags: dg-misc)
*** side-by-side-edit ***
   (3) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
the text area small so it will always fit in the column.
   After page loaded enlarge the text area with Javascript. But
leave a little room (40px) as a margin between the two
   columns. This insurers that side by side always succeeds.
(user: renez tags: side-by-side-edit)
   (4) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
changes so that the branches can be more easily compared.
   (user: drh tags: side-by-side-edit)

Analysing those last two, it's not difficult to see what happened:



The oldest commits were nothing more than merging trunk changes into
the branch. But later the user forgot about that (without seeing the
warning). So it's safe to assume that the older of the two commits
will not be continued upon, and can be closed. Done now.

The fossil self-hosting repository is fork-free now (FWIW) !
Anyway, we still can test the fork-detection on SQLite ;-)
$ fossil forks --bybranch
*** branch-3.7.16 ***
   (1) 2013-04-12 11:52:43 [cbea02d93865ce] Version 3.7.16.2 (user:
drh tags: release, version-3.7.16.2, branch-3.7.16)
   (2) 2013-04-10 03:22:59 [bf6ca21b36ace0] Backport the multi-process
tester to the last released version. (user: mistachkin
   tags: branch-3.7.16)
*** mistake ***
   (3) 2015-03-30 19:56:18 [763d2bc74b560c] Optimize CREATE INDEX,
REINDEX and VACUUM statements by taking better advantage of
   the fact that index keys are being inserted into b-trees in
sorted order. (user: dan tags: mistake)
   (4) 2014-05-28 09:56:34 [7d445e593a9966] Moved to "mistake" because
this commit contains a typo causing a test to fail.
   Was: Add an extra test to further verify that the FTS
notindexed option is working properly. (user: dan tags: mistake)


Hope this helps,
Jan Nijtmans
___
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] Two trunks?

[Matt Welland]

On Thu, Apr 16, 2015 at 1:38 AM, Jan Nijtmans 
wrote:

> 2015-04-14 21:11 GMT+02:00 Andy Bradford:
> > Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
> >> Maybe more  valuable would  be to  adapt the  /leaves page,  so people
> >> searching forks have an easy way to do so.
> >
> > I proposed  this very thing  a few  days ago, and  I think that  this is
> > something  that should  be done  regardless  of the  discussion on  sync
> > warnings.
>
> There's a "fossil forks" command on trunk now:
>
> $ ./fossil forks --bybranch
> *** ben-minorchanges ***
>(1) 2011-09-07 08:12:27 [27a4518e13c41e] Make it easier to use
> Events as quick notes: Display the title just above the text
>on Event pages. If there's no title in the wiki text, use the
> comment as a title. (user: ben tags: ben-minorchanges)
>(2) 2011-08-23 08:37:23 [0f0a94730c0ae9] Cache values of
> versionable settings read from files. (user: ben tags: ben-
>minorchanges)
> *** dg-misc ***
>(3) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
> dg tags: dg-misc)
>(4) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
> dg tags: dg-misc)
> *** msw-docco ***
>(5) 2012-04-19 14:34:59 [626a317e5cea1f] Catch up w/ trunk &
> document --case-sensitive option in the add and addremove
>commands. (user: martin.weber tags: msw-docco)
>(6) 2012-02-10 18:02:40 [587dd57fe194af] climb up the trunk. From
> up here, clarify wording of the "building and installing"
>wiki page: you don't need to log in to get the source code for
> released versions of fossil, the download page will have
>a shiny source package for you to fetch. (user: martin.weber
> tags: msw-docco)
> *** side-by-side-edit ***
>(7) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
> the text area small so it will always fit in the column.
>After page loaded enlarge the text area with Javascript. But
> leave a little room (40px) as a margin between the two
>columns. This insurers that side by side always succeeds.
> (user: renez tags: side-by-side-edit)
>(8) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
> changes so that the branches can be more easily compared.
>(user: drh tags: side-by-side-edit)
>
>
> I used this to close some trivial ones (which were already merged to
> trunk), those are the 4 left at this
> moment. None of them are harmfull, they all lived happily in the
> fossil repo for more than a year.
>

I'm confused by this. If the fork was merged to trunk it is no longer a
fork and should not be detected. Can you elaborate?


>
> Regards,
>Jan Nijtmans
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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] Two trunks?

[Jan Nijtmans]

2015-04-14 21:11 GMT+02:00 Andy Bradford:
> Thus said Jan Nijtmans on Tue, 14 Apr 2015 16:36:18 +0200:
>> Maybe more  valuable would  be to  adapt the  /leaves page,  so people
>> searching forks have an easy way to do so.
>
> I proposed  this very thing  a few  days ago, and  I think that  this is
> something  that should  be done  regardless  of the  discussion on  sync
> warnings.

There's a "fossil forks" command on trunk now:

$ ./fossil forks --bybranch
*** ben-minorchanges ***
   (1) 2011-09-07 08:12:27 [27a4518e13c41e] Make it easier to use
Events as quick notes: Display the title just above the text
   on Event pages. If there's no title in the wiki text, use the
comment as a title. (user: ben tags: ben-minorchanges)
   (2) 2011-08-23 08:37:23 [0f0a94730c0ae9] Cache values of
versionable settings read from files. (user: ben tags: ben-
   minorchanges)
*** dg-misc ***
   (3) 2013-12-19 22:04:43 [22d9cff0c32637] Merge from trunk. (user:
dg tags: dg-misc)
   (4) 2013-10-31 14:41:22 [bbebf7090c6437] Merge from trunk. (user:
dg tags: dg-misc)
*** msw-docco ***
   (5) 2012-04-19 14:34:59 [626a317e5cea1f] Catch up w/ trunk &
document --case-sensitive option in the add and addremove
   commands. (user: martin.weber tags: msw-docco)
   (6) 2012-02-10 18:02:40 [587dd57fe194af] climb up the trunk. From
up here, clarify wording of the "building and installing"
   wiki page: you don't need to log in to get the source code for
released versions of fossil, the download page will have
   a shiny source package for you to fetch. (user: martin.weber
tags: msw-docco)
*** side-by-side-edit ***
   (7) 2012-04-30 09:33:53 [396eceb9e41290] When sided by side make
the text area small so it will always fit in the column.
   After page loaded enlarge the text area with Javascript. But
leave a little room (40px) as a margin between the two
   columns. This insurers that side by side always succeeds.
(user: renez tags: side-by-side-edit)
   (8) 2012-04-29 17:08:44 [82332148a2aa3c] Merge in recent trunk
changes so that the branches can be more easily compared.
   (user: drh tags: side-by-side-edit)


I used this to close some trivial ones (which were already merged to
trunk), those are the 4 left at this
moment. None of them are harmfull, they all lived happily in the
fossil repo for more than a year.

Regards,
   Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users