[fossil-users] Fwd: Re: Conversation with a CM guy

[Andy Goth]

Forwarding to list for further discussion, mail was sent to me privately
though I can't see why.  Must have been inadvertent.

 Forwarded Message 
Subject: Re: [fossil-users] Conversation with a CM guy
Date: Mon, 16 May 2016 15:34:02 -0400
From: John P. Rouillard 
Reply-To: rou...@ieee.org
To: Andy Goth 

Hi Andy:

In message <5ae8586a-678d-2372-80f3-6804af670...@gmail.com>,
Andy Goth writes:
>I suggested he consider Fossil since I have already successfully
>imported his 10K+ Subversion revisions to a private Fossil repository
>(with the help of my andygoth-import branch), and since it's been
>extremely helpful to me and the others from my organization on this
>project.  In particular, it's proven its worth as a go-between linking
>his Subversion repository with our ClearCase repository, which are
>located on private networks at different sites, plus it allows offline
>operation on our laptops, captures development we do directly on the
>target device, and keeps it all in sync through network and file share
>links, whatever is available and when.
> [...]
>He said he thinks he'll go with Git instead because that would give the
>engineers working under him more forward mobility when they eventually
>move on to other companies,

Not totally unreasonable.

> [...]
>The merge problem is when he tries to merge a feature branch into an
>integration branch, he also gets all the other stuff that's been merged
>into the feature branch to virtually update its baseline, even if that
>stuff has not itself yet been deemed ready to merge into the integration
>branch.  The same goes for history research: all that extra is shown as
>changes on the branch relative to its root.

Also I have been playing on and off with implementing the gitflow
workflow using fsl. It allows me to restrict what direction merges
flow (e.g. integration -> feature branch are allowed, but release to
feature branch aren't). This sort of restriction I think helps reduce
the merge issue you are seeing.

It seems a lot of the integration issues are caused by svn. Merge
tracking was always one of svn's issues. It seems to have gotten
better, but I think the DVCS systems still do a better job.

> [...]
>I responded by explaining to him how I handled these same problems in
>Fossil, how I have things organized to track our ClearCase, his
>Subversion, feature branches, and integration branches.  How to merge
>just the pertinent parts even if things otherwise get out of order.  How
>to handle pulling stuff into the Fossil branches that was externally
>added to ClearCase or Subversion.  And so on.  I'm writing an extensive
>document on this.  I concluded by saying I think Fossil can provide what
>he's looking for.

I would like to see your document when you think it's ready to share.
In my case I have perforce rather than clearcase.

>Of course, none of that matters since he started by prioritizing marketing.

Well nobody ever got fired for choosing git (yet). Did you mention to
him that you can import a fossil repo into git if it turns out there
is some killer feature that only git has (although it sounds like
rebase is his killer feature).

I wonder if a git-fossil (like git-svn) might be helpful for people?

Have a great week.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.



signature.asc
Description: OpenPGP digital 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] Repairing trunk/timeline after a shun

[Andy Goth]

On 5/16/2016 8:00 PM, Richard Hipp wrote:
> On 5/16/16, Andy Goth  wrote:
>> I've wanted reparenting capability to support importing old history into
>> a Fossil repository.
> 
> I interpret your sentence above as "I volunteer to test out the new
> code!".  Thanks!

I should have known there'd be a price to pay.

> I added a "fossil reparent" command on the "reparent" branch
> (https://www.fossil-scm.org/fossil/info/5c5a364d5e106d9c).  It is only
> superficially tested so far.  Let me know what problems you find.

I had to make a single-character fix, no big deal.

Here's my first test:

$ alias f=~/fossil/fossil
$ f new shun.fossil
$ mkdir shun
$ cd shun
$ f open ../shun.fossil
$ echo good_data > file
$ f addremove
$ f commit -m good_data
New_Version: 8c70055d3a86ce658b8c32e12fc02d350a5a2efc
$ echo bad_data > file
$ f commit -m bad_data
New_Version: 350e4c5b3f9c85f8b7c31cd0d161d2f7dd5d0b47
$ echo corrected_data > file
$ echo more_bad_data > file2
$ f addremove
$ f commit -m more_bad_data
New_Version: aafdc5705546ef5bd0da111f83b6eedce7269989
$ f rm -hard file2
$ f commit -m 'remove more_bad_data'
New_Version: 14e90133a47d0c119cf0539e4bf60e19d84f9235
# [used web interface to shun the two commits containing bad_data]
# [did not actually shun bad_data and more_bad_data, by the way...]
$ f rebuild
$ f reparent -test 14e9 8c70
$ f rebuild
$ f reparent 14e9 8c70
$ f rebuild

My second test was to stitch together two repositories.

$ f new old_repo.fossil
$ f new new_repo.fossil
$ mkdir checkout
$ cd checkout
$ f open ../old_repo.fossil
checkout: 9495df1464768e21b280947402f1936ae0dcdb28 2016-05-17 04:46:21 UTC
$ echo version_1 > file
$ f addremove
$ f commit -m version_1
New_Version: 45c8061a7462f00e10f8511d1dfc3486c0c67f86
$ echo version_2 > file
$ f commit -m version_2
New_Version: e308d948a2cd23781417fdcbb2caf62991f50d4f
$ f close
$ f open ../new_repo.fossil
checkout: 6542758abd71985d53757bd86b46c2a4162a6eac 2016-05-17 04:46:24 UTC
$ echo version_3 > file
$ f addremove
$ f commit -m version_3
New_Version: e86d82a264de0f2734a8710d0e91a118e43169ac
$ echo version_4 > file
$ f commit -m version_4
New_Version: 1eb483f157614b35448449a57d02290719559798
$ f close
$ cd ..
$ mkdir repo
$ f deconstruct -R old_repo.fossil repo
$ f deconstruct -R new_repo.fossil repo
$ f reconstruct merged_repo.fossil repo
$ f reparent -R merged_repo.fossil e86d e308

I then had to shun 6542758abd71985d53757bd86b46c2a4162a6eac, which is
the initial empty check-in for new_repo.fossil.

The web interface correctly showed the version_3 check-in modifying file
from "version_2" to "version_3", rather than file being created new.

However!

$ f leaves -R merged_repo.fossil
   (1) 2016-05-17 04:47:20 [1eb483f157] version_4 (tags: trunk)
   (2) 2016-05-17 04:46:50 [e308d948a2] version_2 (tags: trunk)

Does a rebuild clear this up?  Not exactly.

$ f rebuild -R merged_repo.fossil
$ f leaves -R merged_repo.fossil

That's right.  Now there are ZERO leaves.

When I open the repository, it picks version_2, not version_4.  Then
when I update, it goes to version_4.

I'm able to make further commits to the repository, but trunk continues
to have no leaf.  Trunk finally acquires a leaf when I make a branch.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Conversation with a CM guy

[Andy Goth]

On 5/16/2016 11:24 PM, Stephan Beal wrote:
> It overwrote the whole drive with the word Hello.

Or at least the first block, which is arguably the most important one
since it tends to contain tables critical to being able to actually find
anything.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Repairing trunk/timeline after a shun

[Andy Goth]

On 5/14/2016 4:59 PM, John P. Rouillard wrote:
> fossil init shun.fossil
> mkdir shun
> cd shun
> fossil open ../shun.fossil
> echo 2 > 2
> fossil addremove
> fossil ci -m "initial commit"
> echo 2a > 2
> fossil ci -m "second commit"
> echo 2b > 2
> fossil ci -m "third commit"
> echo 2shun > 2
> fossil ci -m "fourth shunable commit"
> echo 2c > 2
> fossil ci -m "fifth commit"
> echo 2d > 2
> fossil ci -m "sixth commit"
> 
> then shun the forth commit. You can rebuild the repo if you like it
> makes no difference.

Go look in /bloblist and you'll find that 2shun is still there, even
after a rebuild.  You've not actually succeeded in removing the
dangerous data from your repository.  It's still there despite not being
connected to anything.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Conversation with a CM guy

[Stephan Beal]

It overwrote the whole drive with the word Hello.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
On May 17, 2016 06:11, "Arnel"  wrote:

> On Mon, 16 May 2016 14:39:11 -0400, Richard Hipp wrote:
> > 1985.  I was working at Bell Labs writing horizontal microcode for a
> > signal processing chip.  Development was hosted on a VAX.  There were
> > about a dozen developers all on the same machine.
> >
> > I noticed that the disk drive block devices (/dev/dsk0, /dev/dsk1,
> > etc) all has global rwx permission.  I went to the sysadmin and said
> > "Hey, this a security problem - anybody can write anywhere on the
> > disk!".  "No, he said.  Block devices don't work that way."   I could
> > not convince him otherwise.
> >
> > So I walked back to my VT100 and typed:  echo Hello >/dev/dsk0
>
> Would anyone mind explaining what this command did?
>
> > Neither the sysadmin, nor our manager, nor the other dozen developers
> > using that machine were amused at being off-line for an hour while
> > system was restored...
>
> 
> Thank you,
> Arnel
> ___
> 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] Conversation with a CM guy

[Arnel]

On Mon, 16 May 2016 14:39:11 -0400, Richard Hipp wrote:
> 1985.  I was working at Bell Labs writing horizontal microcode for a
> signal processing chip.  Development was hosted on a VAX.  There were
> about a dozen developers all on the same machine.
> 
> I noticed that the disk drive block devices (/dev/dsk0, /dev/dsk1,
> etc) all has global rwx permission.  I went to the sysadmin and said
> "Hey, this a security problem - anybody can write anywhere on the
> disk!".  "No, he said.  Block devices don't work that way."   I could
> not convince him otherwise.
> 
> So I walked back to my VT100 and typed:  echo Hello >/dev/dsk0

Would anyone mind explaining what this command did? 
 
> Neither the sysadmin, nor our manager, nor the other dozen developers
> using that machine were amused at being off-line for an hour while
> system was restored...


Thank you,
Arnel
___
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] Conversation with a CM guy

[Andy Goth]

On 5/16/2016 1:17 PM, Andy Goth wrote:
> He said he thinks he'll go with Git instead because that would give the
> engineers working under him more forward mobility when they eventually
> move on to other companies, whereas Fossil is unknown and would not
> improve their employability.
>
> [...]
>
> Of course, none of that matters since he started by prioritizing marketing.

I had a thought about Git marketing versus Fossil marketing.

Git's success, at least its initial adoption from which critical mass
formed, is due to it being written by the principal author of Linux for
managing the development of Linux.

Sound familiar?

Fossil was written by the principal author of SQLite for managing the
development of SQLite, and SQLite is arguably MORE successful than
Linux, so... haha.

But then I'm reminded of drh speaking at the 2012 Tcl/Tk Conference,
showing a chart correlating a massive jump in Apple stock with Apple's
adoption of SQLite.  He said this to demonstrate his claimed inability
to market his products, because he's not been able to use this chart to
sway any management types.  (Am I remembering that correctly?)

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Repairing trunk/timeline after a shun

[Richard Hipp]

On 5/16/16, Andy Goth  wrote:
>
> I've wanted reparenting capability to support importing old history into
> a Fossil repository.
>

I interpret your sentence above as "I volunteer to test out the new
code!".  Thanks!

I added a "fossil reparent" command on the "reparent" branch
(https://www.fossil-scm.org/fossil/info/5c5a364d5e106d9c).  It is only
superficially tested so far.  Let me know what problems you find.

-- 
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] No progress on "fossil cp"

[Steve Stefanovich]

>> Not that this is much consolation to you, Warren, or anyone else that ever 
>> had to deal with this, but the merge issue will be fixed in the next release 
>> (or now if you compile your own Fossil binary):

> Thank you, drh!

And thanks to Joel for taking on this long-lasting and annoying bug and 
providing the fix.

This will also improve Fossil reputation when comparing with other VCSes. I've 
seen it used - rightly so, because it is an essential feature for code 
refactoring - as an argument against Fossil on discussions at HN, Reddit and 
elsewhere. 

Cheers,
Steve
___
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] No progress on "fossil cp"

[Warren Young]

On May 16, 2016, at 4:37 PM, Joel Bruick  wrote:
> 
> j. van den hoff wrote:
>> On Mon, 16 May 2016 19:02:17 +0200, Warren Young  wrote:
>> 
>>> 2. If you attempt to merge a change between branches where one of the 
>>> changed files was renamed after the branch point, Fossil will *silently* 
>>> drop all changes to that file.  Then it will lie to you, telling you the 
>>> merge was successful!
>> 
>> I think I also ran into both of these problems and the second one, 
>> obviously, is really bad
> 
> Not that this is much consolation to you, Warren, or anyone else that ever 
> had to deal with this, but the merge issue will be fixed in the next release 
> (or now if you compile your own Fossil binary):

While it would have been nice if this problem never existed, I can’t see how I 
can complain about having a fix within a working day of making the complaint.

Thank you, drh!

___
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] No progress on "fossil cp"

[Joel Bruick]

j. van den hoff wrote:
On Mon, 16 May 2016 19:02:17 +0200, Warren Young  
wrote:


1. f finfo can’t trace file history back through a rename.  The web 
version of this (f ui > Files > Ancestry) does manage to report the 
rename, but it doesn’t trace history back through that link to the 
old name.  Why would I want file history to cut off just because I 
renamed it?
2. If you attempt to merge a change between branches where one of the 
changed files was renamed after the branch point, Fossil will 
*silently* drop all changes to that file.  Then it will lie to you, 
telling you the merge was successful!  If the resulting partial merge 
compiles and runs, you might not immediately notice that you didn’t 
get 100% of the feature/fix.  (This happened to me just a week or two 
ago!)


I think I also ran into both of these problems and the second one, 
obviously, is really bad (and the first one bad enough: it's presence 
heavily discourages one (at least me...) from doing otherwise 
desirable tidyups...). I do hope there is a chance to see this fixed 
in future versions (considering there are users able to recognize a 
problem but not to fix it ;-))


Not that this is much consolation to you, Warren, or anyone else that 
ever had to deal with this, but the merge issue will be fixed in the 
next release (or now if you compile your own Fossil binary):


https://www.fossil-scm.org/index.html/info/41c2220934de8cb8
___
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] No progress on "fossil cp"

[j. van den hoff]

On Mon, 16 May 2016 19:02:17 +0200, Warren Young  wrote:

1. f finfo can’t trace file history back through a rename.  The web  
version of this (f ui > Files > Ancestry) does manage to report the  
rename, but it doesn’t trace history back through that link to the old  
name.  Why would I want file history to cut off just because I renamed  
it?
2. If you attempt to merge a change between branches where one of the  
changed files was renamed after the branch point, Fossil will *silently*  
drop all changes to that file.  Then it will lie to you, telling you the  
merge was successful!  If the resulting partial merge compiles and runs,  
you might not immediately notice that you didn’t get 100% of the  
feature/fix.  (This happened to me just a week or two ago!)


I think I also ran into both of these problems and the second one,  
obviously, is really bad (and the first one bad enough: it's presence  
heavily discourages one (at least me...) from doing otherwise desirable  
tidyups...). I do hope there is a chance to see this fixed in future  
versions (considering there are users able to recognize a problem but not  
to fix it ;-))



--
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] No progress on "fossil cp"

[Richard Hipp]

On 5/16/16, Ross Berteig  wrote:
>
>>> That would require a backwards-incompatible change to the manifest format
>
> Unless some clever trick can be invented that will let older versions of
> fossil simply see such files as newly added at the time of the copy
> while letting a new version also track the history across that event.
>
> I'm not steeped enough in the manifest details to know what is possible
> myself, however.
>

I think this could be done using the existing F-card in the Manifest
artifact 
(https://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki#manifest).
Merely put the name of the file copied from in the old-name field, and
then add a new letter (perhaps "c") to the permissions field to let
Fossil know that the file was copied from old-name rather than moved
from old-name.

The extra "c" character in teh permissions field is necessary to
distinguish between these cases:

Case 1:  (this is not a copy)
  fossil mv abc.txt def.txt
  echo hi >abc.txt
  fossil add abc.txt

Case 2:
  fossil cp abc.txt def.txt


The "c" flag in permissions would only occur for Case2.  There are
other interesting cases to be on guard against, for example:

Case 3:
  fossil mv a.txt temp.txt
  fossil mv b.txt a.txt
  fossil mv temp.txt b.txt

That part is easy I think.  The hard part will be updating the current
Fossil implementation to understand the implications of forks in file
change graphs.

-- 
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] No progress on "fossil cp"

[Warren Young]

On May 16, 2016, at 2:48 PM, Ross Berteig  wrote:
> 
> On 5/16/2016 9:53 AM, Warren Young wrote:
>> On May 14, 2016, at 4:35 AM, Stephan Beal  wrote:
>>> But in svn, now that i think about it, cp is, in practice, only used for 
>>> branching.
>> ...
>> If the SCM doesn’t remember that y.cpp was cloned from x.cpp
> 
> Actually, a copy command would sometimes be nice when refactoring an 
> over-large module into several smaller modules, in that it would preserve 
> more history in a place where it might be sought later.

Yes, I’ve done that under svn, too.
___
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] No progress on "fossil cp"

[Ross Berteig]

On 5/16/2016 9:53 AM, Warren Young wrote:

On May 14, 2016, at 4:35 AM, Stephan Beal  wrote:

But in svn, now that i think about it, cp is, in practice, only used for 
branching.

...
If the SCM doesn’t remember that y.cpp was cloned from x.cpp


Actually, a copy command would sometimes be nice when refactoring an 
over-large module into several smaller modules, in that it would 
preserve more history in a place where it might be sought later.


For extra credit, one might imagine an analysis something like the 
existing annotate/blame features that allows a file that is fragmented 
into several files to preserve only the history pertinent to the bits 
that move to each fragment in that fragment. I have no clue what the UI 
for such a feature should look like, however.


Personally, I usually just treat such copies (or fragments after a 
refactor) as brand new, and get on with life. Tracking everything sounds 
nice on paper, but I'm not sure it is actually worth the required effort.



That would require a backwards-incompatible change to the manifest format


Unless some clever trick can be invented that will let older versions of 
fossil simply see such files as newly added at the time of the copy 
while letting a new version also track the history across that event.


I'm not steeped enough in the manifest details to know what is possible 
myself, however.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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] Conversation with a CM guy

[Warren Young]

On May 16, 2016, at 12:17 PM, Andy Goth  wrote:
> 
> He also said he likes Git's rebase capability

Ask him if the company keeps its books on a whiteboard.  If so, git may be a 
great fit for that company. ;)

___
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] Conversation with a CM guy

[Steve Schow]

me personally, if a potential employer wanted me to be a git guru, I wouldn’t 
take the job.  git gives me headaches beyond anything very simple, which as you 
said, can be learned in a day.

Git was one of the worst things to happen to the world of software engineering.

What makes git useful is the existence of github.  That’s about it.  Otherwise 
its a menace…


On May 16, 2016, at 12:44 PM, Eric Rubin-Smith  wrote:

>  employability. 
> 
> It takes less than a day to pick up git if you're used to fossil.  So I don't 
> really think it makes a huge difference as to future employability unless the 
> hiring manager is looking for the wrong things.
> 
> I grant that most hiring managers *do* look for the wrong things, but let's 
> not base decisions in our current project around the industry's silly hiring 
> practices.
> 

___
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] Conversation with a CM guy

[Eric Rubin-Smith]

>
>  employability.


It takes less than a day to pick up git if you're used to fossil.  So I
don't really think it makes a huge difference as to future employability
unless the hiring manager is looking for the wrong things.

I grant that most hiring managers *do* look for the wrong things, but let's
not base decisions in our current project around the industry's silly
hiring practices.

My $0.02,
Eric
___
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] Conversation with a CM guy

[Richard Hipp]

On 5/16/16, Stephan Beal  wrote:
>
> The web UI offers a "delete branch"
> feature and i'm always _so tempted_ to click it (and click "yes" on the
> subsequent confirmation dialog), _simply to prove a point_.

1985.  I was working at Bell Labs writing horizontal microcode for a
signal processing chip.  Development was hosted on a VAX.  There were
about a dozen developers all on the same machine.

I noticed that the disk drive block devices (/dev/dsk0, /dev/dsk1,
etc) all has global rwx permission.  I went to the sysadmin and said
"Hey, this a security problem - anybody can write anywhere on the
disk!".  "No, he said.  Block devices don't work that way."   I could
not convince him otherwise.

So I walked back to my VT100 and typed:  echo Hello >/dev/dsk0

Neither the sysadmin, nor our manager, nor the other dozen developers
using that machine were amused at being off-line for an hour while
system was restored...
-- 
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] Conversation with a CM guy

[Stephan Beal]

On Mon, May 16, 2016 at 8:17 PM, Andy Goth  wrote:

> I also told him about the Git issues I've read about, particularly how
> fast and loose it plays with preserving history, how branches aren't
> much more than tags identifying the final product of a development
> effort.  I said I can see how this benefits the Linux kernel requirement
> that the maintainers not be overburdened by the blow-by-blow history,
> how they're ultimately only going to want the final product.  But I said
> that disregard for preserving detailed history, including (perhaps
> especially) mistakes, is anathema to me, how important it is that I be
> able to research the detailed development history when I'm tracking down
> when and how things went wrong.
>

A new project at work is using Bitbucket[1] and a workflow which deletes
feature branches when they're merged. The web UI offers a "delete branch"
feature and i'm always _so tempted_ to click it (and click "yes" on the
subsequent confirmation dialog), _simply to prove a point_. It'd mean the
end of my career, but the point would have been made. (That point being
that the ability to delete history, in particular for anyone with commit
access to be able to do so, is fundamentally braindead. "What could
possibly go wrong?")


[1] it's quite a nice tool, actually, from what little i've used it.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Conversation with a CM guy

[Andy Goth]

Today I had a conversation with the guy who handles the configuration
management for the software project to which I'm on loan.

He mentioned that in a couple years he wants to switch away from the old
version of Subversion they're currently saddled with.

I suggested he consider Fossil since I have already successfully
imported his 10K+ Subversion revisions to a private Fossil repository
(with the help of my andygoth-import branch), and since it's been
extremely helpful to me and the others from my organization on this
project.  In particular, it's proven its worth as a go-between linking
his Subversion repository with our ClearCase repository, which are
located on private networks at different sites, plus it allows offline
operation on our laptops, captures development we do directly on the
target device, and keeps it all in sync through network and file share
links, whatever is available and when.

A few weeks ago, he saw Fossil in operation as we spent a few hours
untangling many months of failed and incomplete merges that were done
simply by trading code snapshots which each side diff'ed and claimed to
have incorporated, yet in reality they only took the half of the changes
that appealed to them.  Yet with everything in one place, Fossil enabled
us to make sure it was all done correctly and completely with all
parties in agreement.

He said he thinks he'll go with Git instead because that would give the
engineers working under him more forward mobility when they eventually
move on to other companies, whereas Fossil is unknown and would not
improve their employability.  He also said he likes Git's rebase
capability since he believes it will solve a merge problem he's been
having with Subversion.

The merge problem is when he tries to merge a feature branch into an
integration branch, he also gets all the other stuff that's been merged
into the feature branch to virtually update its baseline, even if that
stuff has not itself yet been deemed ready to merge into the integration
branch.  The same goes for history research: all that extra is shown as
changes on the branch relative to its root.

He said that with rebasing, he can strip all the contributors away from
the branch and focus only on what what changed in the branch itself,
then review and merge only that into the integration branch.

He admitted he hadn't actually tried any of this, had only just read
about it.

I responded by explaining to him how I handled these same problems in
Fossil, how I have things organized to track our ClearCase, his
Subversion, feature branches, and integration branches.  How to merge
just the pertinent parts even if things otherwise get out of order.  How
to handle pulling stuff into the Fossil branches that was externally
added to ClearCase or Subversion.  And so on.  I'm writing an extensive
document on this.  I concluded by saying I think Fossil can provide what
he's looking for.

I also told him about the Git issues I've read about, particularly how
fast and loose it plays with preserving history, how branches aren't
much more than tags identifying the final product of a development
effort.  I said I can see how this benefits the Linux kernel requirement
that the maintainers not be overburdened by the blow-by-blow history,
how they're ultimately only going to want the final product.  But I said
that disregard for preserving detailed history, including (perhaps
especially) mistakes, is anathema to me, how important it is that I be
able to research the detailed development history when I'm tracking down
when and how things went wrong.

Of course, none of that matters since he started by prioritizing marketing.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Repairing trunk/timeline after a shun

[Andy Goth]

On 5/16/2016 11:41 AM, John P. Rouillard wrote:
> Richard Hipp writes:
>> On 5/15/16, Andy Goth  wrote:
>>>
>>> To fix, you're going to have to go back to the version prior to the shun
>>> and redo every check-in since that point.
>>
>> Another option is to "reparent" the first check-in after the shun such
>> that it's parent becomes the last check-in before the shun.  There is
>> a "parent" tag for this purpose.
> 
> That is what I was hoping for. Is there any documentation on the
> parent tag? A full text search of "parent NEAR tag" returns too many hits
> and none of the documentaion hits seem to apply.

I've wanted reparenting capability to support importing old history into
a Fossil repository.

For example, I'm given a snapshot of version 2 of a software system and
am told to use it as my baseline.  I make it be the initial import of a
new Fossil repository, then I do my thing.  But then I have questions
about history, and someone gives me a snapshot of version 1.  I want to
import that so I can do diffs and other things through the Fossil
interface, but I can't without recreating the repository using pretty
much the same technique I outlined in my first reply to this thread.

Another scenario would be me being given CVS, SVN, RCS, Git, or other
history data some time after initially creating my repository from one
or a small number of snapshot versions.  I can import these
incrementally, but I can't retroactively integrate what's imported with
the timeline, only keep it in a branch off to the side.

If I can check in control artifacts to facilitate stitching these
otherwise disparate timelines together, then I'll be able to sanely
manage situations such as the above, as well as fix the hole caused by
shunning a non-leaf check-in.

-- 
Andy Goth | 



signature.asc
Description: OpenPGP digital 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] Unrecognized command-line option, or missing argument: --https

[Warren Young]

On May 14, 2016, at 7:08 AM, Piotr Orzechowski  
wrote:
> 
> You solution seems to work with single repo only.

There are two easy ways to extend it to multiple repos:

1. Point “fossil serve” in the fslsrv wrapper at a directory of *.fossil files, 
not at a single fossil.  Then both of these URLs will work:

https://example.com/code/1st-repo
https://example.com/code/2nd-repo

2. Clone fslsrv for each repository, serving each on a different random 
localhost port, proxying each separately.  Run them all on server startup.

(You’ll have to either remove the bit of the script where it auto-kills the 
previous one or replace it with a /var/run/fslsrv-$reponame.pid scheme so one 
fslsrv script doesn’t kill Fossil instances that don’t belong to it.)

The only reason I can think of to choose this solution over the first is if you 
need each repository to appear somewhere else in the URL scheme.  For example, 
you might be serving each repo on a separate subdomain:

https://1st-repo.example.com
https://2nd-repo.example.com

This also requires adding separate server { } blocks to the nginx configuration 
for the subdomains.
___
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] No progress on "fossil cp"

[Warren Young]

On May 14, 2016, at 4:11 AM, Stephan Beal  wrote:

> Fossil does have an 'mv' command which does retain history.

Kind of.  f mv breaks anything that’s keyed off the file name, since files in 
Fossil are identified by their path within the repo.

I’ve run into two main flavors of this problem, but I wouldn’t be surprised to 
learn that there are more:

1. f finfo can’t trace file history back through a rename.  The web version of 
this (f ui > Files > Ancestry) does manage to report the rename, but it doesn’t 
trace history back through that link to the old name.  Why would I want file 
history to cut off just because I renamed it?

2. If you attempt to merge a change between branches where one of the changed 
files was renamed after the branch point, Fossil will *silently* drop all 
changes to that file.  Then it will lie to you, telling you the merge was 
successful!  If the resulting partial merge compiles and runs, you might not 
immediately notice that you didn’t get 100% of the feature/fix.  (This happened 
to me just a week or two ago!)

There’s a straightforward fix for this, though it’ll probably have to wait for 
Fossil 2: identify files by UUID instead, and store the file name as a 
versioned attribute of the file.

Fossil and Git are the only modern SCMs I know of with this weakness.  hg and 
bk cope much better with file renames.  I seem to recall that even svn did 
better than Fossil in this regard.

> consider:
> 
> scm cp a b
> 
> now my history looks like 'b' has existed as long as 'a’ has

Yes, f fino should show the two files as sharing some history, because that is 
the truth of the matter.

If you “f up 2015-01-01” b should disappear because it didn’t exist back then.

If you then change b and check that in, then:

   f finfo a > a.log
   f finfo b > b.log
   diff a.log b.log

…should show that b has a checkin that a does not.

And if you then “f rm --hard a && f ci", b should continue to exist, and Fossil 
should continue to show all of the history that b inherited from a.
___
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] No progress on "fossil cp"

[Warren Young]

On May 14, 2016, at 4:35 AM, Stephan Beal  wrote:
> 
> But in svn, now that i think about it, cp is, in practice, only used for 
> branching.

No, not “only.”

For example, I have a small repo containing a bunch of test programs.  They’re 
all very similar, sharing perhaps 80-90% of their code, but they’re so small 
that it isn’t worth factoring all of that out into a utility library that they 
all share.

Back when I would create a new one under svn, I could svn cp the existing test 
program that is most similar to what I need the new one to do, then make the 
few changes I needed and check that back in.  This preserves the inherited 
history of the program, even though the program I cloned may go on to receive 
more changes, so that its history diverges from the new one after the cp point.

Each such program I’ve created since switching to Fossil now has an independent 
development history, implying that I created each one de novo.  I might as well 
keep them in separate repositories for all that Fossil is remembering for me 
here.

> i've never seen it used to copy something within the same tree.

I’ve done that on individual files, too.

If the SCM doesn’t remember that y.cpp was cloned from x.cpp, *I* have to, so 
that if I say “f finfo y.cpp” I must then also say “f finfo x.cpp” to get the 
rest of the history of the file.

> That would require a backwards-incompatible change to the manifest format

Fossil 2?
___
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] Repairing trunk/timeline after a shun

[John P. Rouillard]

Hello Richard:

In message