Re: [fossil-users] Repairing trunk/timeline after a shun

[Richard Hipp]

On 5/17/16, John P. Rouillard  wrote:
>
> Is there an expand(content) or something that I
> could use?
>

Use the "content()" SQL function to decode the blobs.  The argument is
any symbolic name (like a prefix of the SHA1 hash).  Example:

 SELECT content('trunk');

Returns the complete text of the check-in artifact for the trunk check-in.

To find the files in a check-in use the files_of_checkin virtual table:

SELECT * FROM files_of_checkin WHERE
checkinid=symbolic_name_to_rid('trunk');


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

[John P. Rouillard]

Hi Andy:

In message <0dc19ff1-f9f1-67af-7119-62bf62462...@gmail.com>,
Andy Goth writes:
>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.

Eep. If I shun a commit artifact, should all the artifacts for that
commit also be shunned? I think the answer is no since shunning should
be an advanced operation.  Mistakenly shunning a commit (rather than a
file) could delete other files that shouldn't be shunned.

Would it be worth mentioning that shunning a commit does not shun the
artifacts checked in during that commit? I kind of expected them to be
removed since they were added as a single transaction. (I understand
why this expectation is wrong but...)

Is there any way to identify and remove these unconnected artifacts?
Would rebuild --vacuum clean them out? I suspect deconstruct would not
dump those disconnected artifacts. So would

   fossil deconstruct
   fossil reconstruct 

make a new repo without the disconnected data.

Is there any way using "fossil sqlite3" to dump the data so I can grep
for the banned data to make sure it's been erased?

As I figured:

   select uuid,content from blob;

doesn't do it.  Is there an expand(content) or something that I
could use?

In any case, thank you for showing the error of my ways. I have to
shun the files with the privileged info and not the commit (unless the
privileged info is in the commit message). Well back to trying to
sanitize things.

Have a great week.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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

[John P. Rouillard]

Hi Eric:

In message
 ,
Eric Rubin-Smith writes:
>>  employability.
>
>
>It takes less than a day to pick up git if you're used to fossil.

I agree with you to an extent. There are some sharp edges in git that
people seem to cut themselves on. If you are hiring people you don't
want to have to train to avoid/be able to bandage themselves then it's
not a 1 day deal.

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

No argument here.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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

[John P. Rouillard]

In message <4d41a0c9-37e8-1a0b-2120-99953b016...@gmail.com>,
Andy Goth writes:
>On 16 May 2016 15:34:02, John P. Rouillard  wrote:
>> I would like to see your document when you think it's ready to share.
>
>I can't, it's not mine to share.  And even if I were willing to spill
>proprietary information, the document is heavily tailored to the project
>I'm working on, full of host names and engineer names and site names and
>version names and internal process references and all that.

Fair enough. A lot of the doc I write professionally is releasable
and supported as part of the open source effort at the companies I
have worked at.

However that's not the type of doc you are writing 8-).

>I might someday write a more generic document on my own time.  I'll
>partially outline it below.
>
>> In my case I have perforce rather than clearcase.
>
>I've integrated Fossil with Perforce in pretty much the same way.  The
>secret is the "-keep" option to open.  Create the checkout directory
>using the other SCM tool, then use "-keep" to ask Fossil to manage it
>without overwriting it.  Then use "f checkout -force -keep" to go from
>version to version while still not overwriting anything.
>
>[ very useful and interesting info removed ]
>
>Oh right, renames.  I guess you're going to want to track those too.  I
>haven't thought about them much because the way we're using ClearCase
>completely prevents rename tracking.

Ok. Yeah renaming would be useful. I don't know how it's handled in
perforce, but I assume some sed magic on some query option can provide
the commands to mirror the renames across repos.

>And now we're talking about having Fossil track copies too.  Once again,
>I don't know how to apply that to the process I'm outlining.

Fair enough.

>I'm not sure this is what you wanted to read about.  Maybe you wanted
>workflow within Fossil, like how to manage branches.

That would also be useful, but we are using perforce streams so the
same promotion/restricted merge mechanism can be enabled using fsl I
think.

>Or maybe you
>wanted to know how to synchronize despite lacking end-to-end network
>connectivity.

No, not so interested in that 8-).

>>> Of course, none of that matters since he started by prioritizing
>>> marketing.
>> 
>> Well nobody ever got fired for choosing git (yet).
>
>One person being fired for a poor decision is preferable to the whole
>shop having to bear a long-term burden that eats their competitive
>advantage and their morale, possibly leading to turnover or layoffs.

I agree, but the same can be said about using Microsoft or IBM 8-).

>> I wonder if a git-fossil (like git-svn) might be helpful for people?
>
>I don't know what git-svn is.

It's a git command that treats an svn as an upstream repo. There is
also git-p4 IIRC.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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 17, 2016, at 12:25 PM, Ron W  wrote:
> 
> So far, none of the IDEs I've used seem to support VCS merges from within the 
> IDE.

Visual Studio does, with Git:

  https://www.visualstudio.com/en-us/get-started/code/merging-with-squash
___
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]

>
>
> So far, none of the IDEs I've used seem to support VCS merges from within
> the IDE. I've always had to go to the VCS itself (or, when using Hg or SVN
> on Windows, TortoiseHg or TortoiseSVN), so lack of merging in libfossil
> might not be a big issue for creating Fossil plug-ins for IDEs.
>
> A GUI for Fossil would benefit from merge support in libfossil, but could
> work around it.
>
> I'll think about taking over libfossil. My main concern is that my
> employer's legal department won't allow me to sign the Fossil copyright
> assignment document.
>

EGit, the git plugin for Eclipse, does merges.

The existence of the Eclipse plugin is the only reason we went with Git for
the project rather than Fossil -- some of the devs in my team seem only be
able to do work via Eclipse and have no experience with the command line
etc.

The merge feature works, until it doesn't.

A week or two ago EGit worked together with git, Eclipse, and a coworker to
lose some of the coworker's code.  I'm not really sure how it happened.
You just look into the VCS history tree and you see a commit with the
message "Inconsistent merge state" (a message generated by EGit).  The
commit tree is hard to understand from the available GUIs, so that doesn't
help.

The message would more rightly have said "I'm deleting some of your code
not telling u which files haha sux 2 B U".

I think it had something to do with making extra changes on top of an
uncommitted merge that had had conflicts, which then confused git and/or
EGit down the line.  But I don't really know.

In any case, it wasn't until yesterday that the coworker noticed a bunch of
his code was missing.  I had to go perform some git-fu (at which I'm a
mid-ranking white belt at best) to figure out what had been lost to some
measure of certainty.  Then the coworker just applied the patch I had
generated by hand to the latest commit in his branch, and we were off to
the races again.  Pretty horrible.

So, there's a market of at least 1 team that would love a Fossil plugin for
Eclipse.  It would be ironic if Fossil's killer use case wound up being its
support of a best-of-breed IDE plugin.  Fossil's original author is
definitely not a big IDE guy. :-)

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

[Ron W]

On Tue, May 17, 2016 at 2:22 PM, jungle Boogie 
wrote:
>
> If fossil had a more polished gui to move files and bring up boxes to
> type in commit messages, it may be more popular too. As it is, most
> fossil commands seem straight forward in my use cases.
>

Some of my co-workers use Fuel (on Windows) as a front end GUI to Fossil.
For some operations, it spawns fossil.exe. For other operations, it
communicates with a running Fossil server (which it can spawn as "fossil ui
$repo" if the user asks, or can use a separately launched Fossil server).
For many users, it probably exposes too much of the way interacts with a
Fossil server, but does make using Fossil easier.

I've also heard of #Fossil (also Sharp Fossil), but never seen it as no one
I work with uses it.

Up until 2 years ago, our preferred IDE was SlickEdit, a commercial IDE
that runs on Linux as as well as Windows. It has support for interacting
with any command line VCS. This worked well for my co-workers and I.

Unfortunately, the top open source IDEs (Eclipse, CodeBlocks, Jedit and a
few others) seem to not support interacting with command line VCS and seem
to be uninterested or unfriendly to the idea.
___
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

[Ron W]

On Tue, May 17, 2016 at 9:00 AM, Stephan Beal  wrote:

> On Tue, May 17, 2016 at 2:10 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
>>
>> And ways to integrate Fossil to popular solutions like MSVS and Visual
>> Studio Code appear to be of increasing relevance to me (I mean, more
>> and more people with simple demands appear to use VC right from their
>> IDEs).
>>
>
> To this end: i will be happy to hand over libfossil to anyone capable of
> taking it over. My elbow nerve injury has never fully recovered, leaving me
> unable to program (or type much at all) aside from the 50-100 lines/day
> intelliJ practically types for me at work. It's not clear whether it will
> ever fully recover (it did, briefly, over the Christmas break, but broke
> again after about 6 weeks of ~50% workloads). The big missing feature in
> libf is merging. Once that's in place, "it's all downhill."
>


So far, none of the IDEs I've used seem to support VCS merges from within
the IDE. I've always had to go to the VCS itself (or, when using Hg or SVN
on Windows, TortoiseHg or TortoiseSVN), so lack of merging in libfossil
might not be a big issue for creating Fossil plug-ins for IDEs.

A GUI for Fossil would benefit from merge support in libfossil, but could
work around it.

I'll think about taking over libfossil. My main concern is that my
employer's legal department won't allow me to sign the Fossil copyright
assignment document.
___
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

[jungle Boogie]

On 17 May 2016 at 05:10, Konstantin Khomoutov
 wrote:
> Unfortunately, the major selling points of Subversion -- excellent
> Windows support including (proprietary) server-side solution with GUI
> configurator and TotroiseSVN -- do not exist for Fossil.  Or at least
> they are not visible well enough.


Sounds a lot like git and github. Git is probably as popular as it is
because of github, not because of git itself.

TotroiseSVN makes things easier for svn so the users don't have to
type all the commands.

If fossil had a more polished gui to move files and bring up boxes to
type in commit messages, it may be more popular too. As it is, most
fossil commands seem straight forward in my use cases.

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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] git rebase, and what it looks like in Fossil

[Ron W]

On Tue, May 17, 2016 at 4:21 AM, Andy Goth  wrote:
>
> So what would a Fossil analogue be?  For simple cases, merge -baseline
> root:branch does the trick.
>
> But if the branch being merged also includes merges from other branches
> for the purpose of updating its baseline, those merges need to be backed
> out as well.
>
> Yet there could be other merges into the branch that need to be kept
> since they're coming from other branches that themselves will never be
> merged into the target of the first merge.
>
> How to distinguish between the last two cases?


I don't think git rebase automates this. As best I've been able to discern,
it automates certain types of sequential merges to help in relocating a
branch from one baseline to another. The hard work of determining what to
back out and/or cherry pick still requires a lot of human direction.

However, I've never actually had to use rebase, The projects I've
contributed to that use git have only asked me to rebase against trunk
(what git users call "master"). For the changes I did, All I had to do was
update trunk from git, merge truck to my branch (which I did in Fossil (or
SVN before I discovered Fossil)), then either make a patch against trunk or
do a git merge to trunk, push to my repo on github and make a pull request.
The core devs never said anything about my changes being only single
commits.
___
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 Tue, May 17, 2016 at 2:10 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> Unfortunately, the major selling points of Subversion -- excellent
> Windows support including (proprietary) server-side solution with GUI
> configurator and TotroiseSVN -- do not exist for Fossil.  Or at least
> they are not visible well enough.
>
> And ways to integrate Fossil to popular solutions like MSVS and Visual
> Studio Code appear to be of increasing relevance to me (I mean, more
> and more people with simple demands appear to use VC right from their
> IDEs).
>

To this end: i will be happy to hand over libfossil to anyone capable of
taking it over. My elbow nerve injury has never fully recovered, leaving me
unable to program (or type much at all) aside from the 50-100 lines/day
intelliJ practically types for me at work. It's not clear whether it will
ever fully recover (it did, briefly, over the Christmas break, but broke
again after about 6 weeks of ~50% workloads). The big missing feature in
libf is merging. Once that's in place, "it's all downhill."


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

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

[Ron Aaron]

On 17/05/2016 15:10, Konstantin Khomoutov wrote:
> I think its an overestimation.  Don't forget that the landscape of
> F/OSS VC systems was different back then.  In reality, DVC systems
> existing around year 2005 were either slow (Monotone, Darcs) or had
> horrible UI (GNU Arch) so Torvalds had nothing to pick from.
Indeed.
> In my opinion the best marketing strategy for Fossil would be to
> compete with Subversion as trying to be a safe go-to solution for shops
> with "simple" demands.  I think the statements made by one of
> Subversion developers in his «Version Control and “the 80%”» rant [1]
> pretty much explain why those who like Git won't switch to Fossil but
> how a simpler solution could help "the 80%" to cope with version
> control.
Also indeed :)

I use Fossil exclusively for all my projects (such as 8th and Reva
Forth) and I try to convince my smaller clients that it is worthwhile
for them to adopt its use.  Many of those clients do not have any kind
of SCM, or use something like Dropbox in lieu of SCM.  And the small
clients who use git are often quite happy to find something much simpler
to use, which answers all their actual needs.

-- 
Best regards,
Ron Aaron
+1 425.296.0766
+972 52.652.5543
___
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

[Konstantin Khomoutov]

On Mon, 16 May 2016 23:06:59 -0500
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.

I think its an overestimation.  Don't forget that the landscape of
F/OSS VC systems was different back then.  In reality, DVC systems
existing around year 2005 were either slow (Monotone, Darcs) or had
horrible UI (GNU Arch) so Torvalds had nothing to pick from.

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

In my opinion the best marketing strategy for Fossil would be to
compete with Subversion as trying to be a safe go-to solution for shops
with "simple" demands.  I think the statements made by one of
Subversion developers in his «Version Control and “the 80%”» rant [1]
pretty much explain why those who like Git won't switch to Fossil but
how a simpler solution could help "the 80%" to cope with version
control.

Unfortunately, the major selling points of Subversion -- excellent
Windows support including (proprietary) server-side solution with GUI
configurator and TotroiseSVN -- do not exist for Fossil.  Or at least
they are not visible well enough.

And ways to integrate Fossil to popular solutions like MSVS and Visual
Studio Code appear to be of increasing relevance to me (I mean, more
and more people with simple demands appear to use VC right from their
IDEs).

1. http://blog.red-bean.com/sussman/?p=79
___
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] Suggestions for list of branches in web-UI

[Baruch Burstein]

On Thu, May 12, 2016 at 12:48 AM, Marko Käning 
wrote:

> 2) /brlist should NOT show closed branches (but could have a menu item for
> that). On page /brlist?all the link “Open" leads straight away to /brlist
> which is showing all existing branches, which is INCONSISTENT!
>

> 3) The pages for /brlist?all, /brlist?open and /brlist?closed should have
> the same table layout like the /brlist?all page generates it, or are they
> deliberately crippled for some reason?
>

The all/open/closed pages were the old style of the brlist page. The new
style, which is a table instead of a list, makes the old pages obsolete
since the information is now all available in the (sortable) column
"status". They were not removed, but there was no reason to "update" them
either.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] git rebase, and what it looks like in Fossil

[Andy Goth]

As discussed previously, for some people rebase is the killer feature
that makes git worthwhile.  Yet we don't have it in Fossil, not with
that name anyway.  I admit my understanding of rebase is very limited,
never having used git.  But I gather it distills a branch down to the
changes actually performed on that branch, not including merge
contributors done for the purpose of updating its baseline, then plonks
those changes on top of a new baseline as if that's where it started
from in the first place.

So what would a Fossil analogue be?  For simple cases, merge -baseline
root:branch does the trick.

But if the branch being merged also includes merges from other branches
for the purpose of updating its baseline, those merges need to be backed
out as well.

Yet there could be other merges into the branch that need to be kept
since they're coming from other branches that themselves will never be
merged into the target of the first merge.

How to distinguish between the last two cases?  One possible heuristic
is to check whether or not the merge is coming from a closed leaf,
though of course this is not guaranteed to be correct.

So, how does this stack up against git rebase?  Not ever having used
git, let alone git rebase, I can't say.  But this algorithm does work
for me in my situation.

If this algorithm were to be automated as a new merge type, what would
the option be?  "merge -rebase" doesn't satisfy me because (as far as I
know) git rebasing is different than Fossil merging in that it operates
on a branch rather than the current checkout.  Perhaps "merge -isolate"
because it isolates the changes made on the branch from the changes
merged into the branch (while still keeping those integrated into the
branch with -integrate).

First, a little review.  A multi-argument P-card signifies a vanilla
merge, and it affects the baseline identification algorithm of future
merges.  Q-cards signify cherrypick and backout merges, denoted by use
of "+" or "-", but they don't currently affect anything, not even the
timeline display.

How would an isolation merge Q-card look in the manifest?  I suggest
tagging it with "!" which resembles an "i" for isolation, and also
resembles a vertical line with a hole in it, pictorially indicating a
single branch but skipping a few things.  Then of course follow the "!"
with the check-in that was merged from.

I'd like to say that if we decide to go with the "closed" heuristic I
describe above, it's not necessary for the isolate Q-card to also
identify which contributors to that branch were kept or backed out since
Fossil can figure out which branches were opened and closed at the time
the merge was performed.  But that's actually not true since it's
possible to close and open branches between performing the isolation
merge and performing the actual check-in.  So instead list the included
merges too.  (Or list the excluded merges.  Or list both, preceded by
"+" and "-".  Just pick a convention and stick with it.)

Here's a graphical example.

G
| .--->F
|>E<-. |
| |  D-'
C |  |
|  B--'  |
A--'-'

E was made by checking out B, merging C, integrating D (i.e. D is
closed), then checking in on a branch.  F was made by checking out D,
doing an isolation merge of E, then checking in on another branch (since
D is closed).

F's manifest reads in part, where E and D are replaced with the
40-character artifact IDs of same:

Q !E D

meaning that it isolation-merges E, backs out C, but does not back out D.

F includes the diff from B to E minus the diff from A to C.

An alternate, backward-compatible approach would be using multiple
cherrypick and backout Q-cards.  In the above case, this would be:

Q +E B
Q -C A

What would an isolation Q-card do?  Probably nothing.  If cherrypick and
backout Q-cards do nothing, neither should isolation Q-cards.

How should it be displayed?  Other Q-cards aren't displayed, but that is
something I definitely would like to see changed.  I previously proposed
using different colors, arrowheads, and dash patterns for cherrypicks
and backouts.  This idea could be extended, but I can't imagine a
sensible way to graphically show inclusion or exclusion of contributors
to the branch being merged.  So I'm going to default to not showing that
since the user can make a good guess based on which are opened and closed.

By the way, until now I never considered the possibility of a range of
versions being included in the cherrypick/backout merge, and I have no
idea how how to show the range.  Again I guess it's better to not try.

It's very late, and I have a plane to catch tomorrow, so those are all
the thoughts I can squeeze out for one night.

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

[Arnel]

On Mon, 16 May 2016 23:30:16 -0500, Andy Goth wrote:
> 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.

Thanks! It's nice to be able to say 'Yikes!' when I read something
like that without having to think 'Wait, what exactly did that do?' next.


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

[Arnel]

On Tue, 17 May 2016 01:03:41 -0500, Andy Goth wrote:
> > I wonder if a git-fossil (like git-svn) might be helpful for people?
> 
> I don't know what git-svn is.

It lets you manage your commits to Subversion using Git. Sort of a two-way
bridge between SVN and Git, and related what you described in the earlier
part of this email (managing commits with Fossil and Perforce/Clearcase).


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

[Arnel]

On Mon, 16 May 2016 23:06:59 -0500, Andy Goth wrote:
> 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?

Calling the developers of another revision control system "ugly and
stupid" in a roomful of Google developers probably helped. :)


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 16 May 2016 15:34:02, John P. Rouillard  wrote:
> Andy Goth writes:
>> 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.

I like that he has his crew's future in mind, but I'm not sure this is
the most helpful thing to them.  It was said elsewhere in this thread
that teaching someone to use Fossil gives them nearly all of what they
need to use Git, at least its saner aspects.

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

One funny thing I saw a lot of while importing his Subversion repository
into Fossil was several instances of moving a branch into a subdirectory
of trunk rather than merging it into trunk.  So if the branch were
called /branches/foo and had a file /branches/foo/bar, he'd end up
adding /trunk/foo/bar instead of merging into /trunk/bar.  Of course he
always followed that up with a correction, but it still permanently
clutters Fossil's all-files display.

Another funny thing was the way he closed completed branches.  His goal
was to hide the branches from most displays since he had quite a lot of
them (remember, over 10K revisions), but he couldn't delete them since
that would make them very difficult to review later, due to needing to
rewind to an unspecified old revision immediately before the delete.  So
instead he moved the branch to a subdirectory of a special branch called
/branches/deleted.  If the branch was called /branches/foo, he'd move it
to /branches/deleted/foo.

That solved his problem nicely, but it created a new one for me.  My
Fossil import showed lots and lots of merges onto deleted, and if I
opened the deleted branch, I'd get a massive checkout containing a copy
of single branch that ever was "deleted" in this fashion.  Plus it
cluttered the all-files display far worse than the comparatively small
number of merge errors described above.

To declutter my display (like the CM guy's original goal), I added the
-ignore-tree feature which I believe I described elsewhere.  Then I
passed "-ignore-tree /branches/deleted" to fossil import, and all was
well.

So yeah, Subversion branch and merge handling are kind of weak, at least
in the version being used.

> I would like to see your document when you think it's ready to share.

I can't, it's not mine to share.  And even if I were willing to spill
proprietary information, the document is heavily tailored to the project
I'm working on, full of host names and engineer names and site names and
version names and internal process references and all that.

I might someday write a more generic document on my own time.  I'll
partially outline it below.

> In my case I have perforce rather than clearcase.

I've integrated Fossil with Perforce in pretty much the same way.  The
secret is the "-keep" option to open.  Create the checkout directory
using the other SCM tool, then use "-keep" to ask Fossil to manage it
without overwriting it.  Then use "f checkout -force -keep" to go from
version to version while still not overwriting anything.

All the Fossil query commands work (changes, extras, diff), and in my
experience orders of magnitude faster than their ClearCase counterparts.
For the repository sizes and slow servers I'm used to, they finish in a
couple seconds instead of a couple minutes.

Importing to Fossil is essentially a three-step process.

1. Make sure (without writing anything to disk) that Fossil checkout is
set to the version immediately prior to the check-in you wish to create.
You may already be there, especially in the common case where you're
doing multiple in a row.  But if not, use "f checkout -force -keep
VERSION" to get there.

2. Use the other SCM system to select the version to import, upating all
the files in the checkout directory.

3. Commit the files into Fossil, including adds and deletes.  Run
changes and extras to see what needs doing, then do it.  You may wish to
give the check-in a tag cross-referencing it with the other SCM system's
versioning scheme.

Going the other way is basically the reverse.  As a prerequisite, it's
best to have your check-ins ready to go in Fossil before you try putting
them in the other SCM system.  By that I mean if you do your work on
separate feature branches, first merge them to trunk before you try
putting trunk into any other SCM system.  The reason for this is some
systems (e.g. ClearCase) keep the checkout files read-only until you