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

2016-05-18 Thread Piotr Orzechowski 
And so does IntelliJ: 
https://www.jetbrains.com/help/idea/2016.1/merging-deleting-and-comparing-branches.html#d1537633e130.
Regards,
Orzech
Dnia 17 maja 2016 21:01 Warren Young w...@etr-usa.com napisał(a):
On May 17, 2016, at 12:25 PM, Ron W ronw.m...@gmail.com 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
___
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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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] Conversation with a CM guy

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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] Conversation with a CM guy

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

2016-05-17 Thread 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

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

2016-05-16 Thread 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] Conversation with a CM guy

2016-05-16 Thread 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

2016-05-16 Thread 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

2016-05-16 Thread 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] Conversation with a CM guy

2016-05-16 Thread 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

2016-05-16 Thread 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

2016-05-16 Thread 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

2016-05-16 Thread 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

2016-05-16 Thread 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

2016-05-16 Thread 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