Re: [fossil-users] xkcd on git

[Scott Doctor]

I did not say I did not use version control. By VCS I refer to 
the programs such as fossil, git, mercurial... used for doing 
such. I am using Fossil for my current project in parallel with 
my own way of handling versions. Embarcadero RAD Studio 
incorporates Git, Mercurial, and Subversion into the IDE. Had 
issues with them, so I tried fossil. Still evaluating its utility.


What I meant was I end up spending much time trying to get the 
tools to do what I want it to do versus how it wants to do it. 
Especially when new to the system, a GUI interface is much 
better than having to work with yet another list of command line 
formats.


I fully see the utility of a VCS on collaborative projects. My 
project is for my own research work and is not used by any 
clients. I am also the only one who plays with my code. So some 
of the utility needed for collaborative efforts becomes 
cumbersome for a solo project.


I have a directory tree on various backup drives of my old 
versions, one-off programs, and a huge library of my own 
utilities. The development system I use (Embarcadero RAD Studio) 
has a built-in program manager which juggles the various files 
required for the build.


Before I start writing a new function, process, or other 
modification, I create a sub-folder of my backup folder which 
are numbered in sequence. The file system applies a date to the 
creation time of the folder which identifies when the backup was 
made. I then simply copy my entire project folder into the 
backup folder. If I break the code, or decide to revert the 
changes, I restore the project from the desired backup folder. 
This is a bit cumbersome way of handling versions, especially 
given my main program consists of more than 250 files. Such is 
why I am trying out various VCS systems. I am finding them just 
as cumbersome of a process with an added layer of things to go 
wrong.



Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 12:59 PM, Richard Hipp wrote:

On 10/30/15, Scott Doctor  wrote:

That is my experience with all VCS systems. Even with fossil, I
am having trouble justifying why the hassle is worth the effort.


What do you do when a customer calls to ask about code you sent them
18 months ago?  How do you figure out what version of the code they
are running?

When you find an obscure bug that you know was not in the release from
December 2012 but might have been introduced anytime between then and
now, how do you figure out when it was introduced?

How do you add experimental features and make experimental changes?
Do you just start hacking away and hope the changes don't break
anything?

How do you identify versions of your code to your customer?

How do you verify that no stray changes have been introduced into your code?

How do you backup your code?

When you have multiple people collaborating on the same project, how
do you coordinate their changes and ensure that features added by one
developer don't get overwritten and erased by another developers.  How
do you know who is working on what?  Can you even identify what you
code is?

Seriously.  I don't understand how it is possible to make reliable
software without good version control.  Is the foundation of
everything.




___
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] xkcd on git

[sky5walk]

​"​
Even with fossil, I am having trouble justifying why the hassle is worth
the effort.
​"
​
Sorry, but the alternatives
​(I have a Halloween shudder at the thought)​

​are way more effort in the long run.​
I agree, merging is difficult when there are conflicts. But, Fossil and
others show your options to proceed. You are in control.

On Fri, Oct 30, 2015 at 4:08 PM, jungle Boogie 
wrote:

> On 30 October 2015 at 10:56, Scott Doctor  wrote:
> > That is my experience with all VCS systems. Even with fossil, I am having
> > trouble justifying why the hassle is worth the effort.
>
>
> I version control config files for apps, .vimrc files, and small
> scripts just so I can see what changes I make between them and for
> faster setup on new machines. In my very simple setup, I see clear
> benefits of using version control (Fossil and rcs) on these files. I
> can't imagine how serious software dev would work without some form of
> version control.
>
> --
> ---
> 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
>
___
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] xkcd on git

[Warren Young]

On Oct 30, 2015, at 2:37 PM, Scott Doctor  wrote:
> 
> Embarcadero RAD Studio incorporates Git, Mercurial, and Subversion into the 
> IDE.

Yes, it would be nicer if more IDEs had Fossil plugins.

That said, I always have a terminal window up, cd’d into the project, so even 
when using something like Visual Studio, a quick Alt-Tab and “f ci” is no 
trouble.

> What I meant was I end up spending much time trying to get the tools to do 
> what I want it to do versus how it wants to do it.

Examples, please.

> I fully see the utility of a VCS on collaborative projects. My project is for 
> my own research work and is not used by any clients. I am also the only one 
> who plays with my code. So some of the utility needed for collaborative 
> efforts becomes cumbersome for a solo project.

I’ve used Fossil for solo work, and it’s still greatly preferable to the 
alternatives.  In addition to drh’s points:

1. Multi-machine sync.  I view laptop computers as a compromise, something to 
use when you can’t use a desktop computer.  Since I can’t always restrict my 
coding activities to a single location, that means I occasionally have to sync 
my work to a laptop, or between two different desktops.  Fossil does that, and 
does so in a much easier fashion than other DVCSes.  (f all sync!)

Dropbox and such are poor alternatives, since I don’t want my object files and 
executables sync’d to the cloud, and I don’t want to see a throbby little icon 
in the corner of my vision every time I save a file.  I want to batch my syncs 
up, do them on my schedule, and send only source files, no object files.

2. Deduplication.  Your versioning scheme requires needless copies of unchanged 
files.  Fossil only stores what is needful, which means I can download the 
entire history of a project without even thinking about it.

I suspect if you checked all the past versions of your system into a single 
Fossil repo, it would be about the size of 3 or 4 of your existing “whole 
project” archives.  So, you’ve got a choice: in the same bandwidth/disk space 
as a handful of archives, you can have all the history, or just the most recent 
history.

3. Comments.  I used to keep a paper log book of the things I was working on, 
so I could go back later and figure out what I did and why.  Searching the 
comment stream of a Fossil timeline is far better.

4. Wiki and technotes.  When I have too much to say to fit into a comment box, 
I can write an article about it, which gets sync’d to my various development 
machines.

5. Tickets.  I used to keep a Wishlist or TODO file in each project, containing 
the things I wanted to do next.  Tickets do that better, since you can 
prioritize them, search them, reference them from checkin comments and wiki 
articles, etc.

You can have my Fossil after I *become* a fossil. :)

> Before I start writing a new function, process, or other modification, I 
> create a sub-folder of my backup folder which are numbered in sequence. The 
> file system applies a date to the creation time of the folder which 
> identifies when the backup was made. I then simply copy my entire project 
> folder into the backup folder.

This is easier than “fossil ci --tag v1.2.3” or “fossil ci --branch 
expermental-feature”?

For solo projects, branch merging is nearly trivial, since the chances of 
colliding changes is near-zero.

And if you do find yourself changing the same area of code on two different 
branches, it’s easy to say something like “f merge trunk” from the branch to 
sync changes made in the trunk into the experimental branch, so you can 
overwrite some of the recent trunk changes without confusing Fossil.

> If I break the code, or decide to revert the changes, I restore the project 
> from the desired backup folder.

That’s easier than “f up trunk” to toss a bad branch, or “f revert” to toss 
uncommitted changes, or “f up v1.2.3” to roll back to a prior stable version?

> I am finding them just as cumbersome of a process with an added layer of 
> things to go wrong.

I rarely find Fossil failing in ways I can’t understand.  And every time it has 
happened, someone on the list has explained it.

(For instance, my recent thread about how to clip off a a branch via the 
command line when the UI can’t do it because it was created empty, something 
Fossil can’t do, but which apparently CVS or SVN can, so it got into my Fossil 
tree when I converted.)

This as compared to the sentiment in the XKCD comment, where if Git screws up, 
it’s often simpler to just toss the checkout and start over than try to recover.

Another example is the “double tip” stuff we’ve seen on the list.  Fossil now 
diagnoses that problem, allowing you to correct it before it becomes a serious 
problem.

For the most part, Fossil obeys the principle of least astonishment.

Maybe that’s because I’ve been conditioned by ~15 years of CVS and SVN, so I 
know how VCSses are supposed to work.  If so, this is where we need your 

Re: [fossil-users] xkcd on git

[Stephan Beal]

On Oct 30, 2015 21:37, "Scott Doctor"  wrote:
>
>
> What I meant was I end up spending much time trying to get the tools to
do what I want it to do versus how it wants to do it.

i would argue that that's backwards (and possibly the source of your
frustration with SCM). Software is designed to work a certain way, not
necessarily be bent to work how one wants it to. No word processor works
how i _want_ it to, yet there is not much i can do about that. That doesn't
decrease their utility if i adjust my expectations to how they are intended
to work.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
___
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] SHA1 and security

[Michal Suchanek]

On 30 October 2015 at 00:32, Eduard  wrote:
> Hi Warren,
>
> On 10/29/2015 06:50 PM, Warren Young wrote:
>> On Oct 29, 2015, at 3:40 PM, Eduard  wrote:
>>> On 10/29/2015 02:46 PM, Warren Young wrote:
 (...)
>>> I had read 2/3 of them, yes. Thanks for the third one!
...
>>> I might know (through some other source, e.g.
>>> PGP-signed email) that artifact "abcdef" is genuine, and it shouldn't
>>> matter where I download it from.
>>
>> How many people will be doing such cross-checking?
>>
>> Again I bring up the XcodeGhost example.  People do foolish things in the 
>> name of expediency.
>
> Well, I know I will be doing such cross-checking. Hopefully I'm not the
> only one. Right? ...right?

Seriously, large part of the software out there is not signed in any way at all.

For codebase of non-trivial size (more than 2-3 small files) there is
no way to review the code.

It does not suffice to sign the security software. Since we have the
poor security design dating back to the original Unix implementation
all application are allowed to do anything. There are optional
security extension like selinux that technically do allow sandboxing
applications by now but most applications would fail if running
sandboxed because these are optional non-standard extensions. Who
would bother to cater to people who use those to be able to run their
system securely, right?

So you have to trust every single line of code and makefile you run.
Not just the system tools. *everything* you ever download and execute
on your computer. Even proprietary applications and libraries (how
many vendors do sign these?).

So basically any 'security' on a workstation where you actually do
anything useful is just fake.

Thanks

Michal
___
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] xkcd on git

[Michal Suchanek]

On 30 October 2015 at 23:19, Warren Young  wrote:
> On Oct 30, 2015, at 2:37 PM, Scott Doctor  wrote:
>>
>> Embarcadero RAD Studio incorporates Git, Mercurial, and Subversion into the 
>> IDE.
>
> Yes, it would be nicer if more IDEs had Fossil plugins.
>
> That said, I always have a terminal window up, cd’d into the project, so even 
> when using something like Visual Studio, a quick Alt-Tab and “f ci” is no 
> trouble.
>
>> What I meant was I end up spending much time trying to get the tools to do 
>> what I want it to do versus how it wants to do it.
>
> Examples, please.
>
>> I fully see the utility of a VCS on collaborative projects. My project is 
>> for my own research work and is not used by any clients. I am also the only 
>> one who plays with my code. So some of the utility needed for collaborative 
>> efforts becomes cumbersome for a solo project.
>
> I’ve used Fossil for solo work, and it’s still greatly preferable to the 
> alternatives.  In addition to drh’s points:
>
> 1. Multi-machine sync.  I view laptop computers as a compromise, something to 
> use when you can’t use a desktop computer.  Since I can’t always restrict my 
> coding activities to a single location, that means I occasionally have to 
> sync my work to a laptop, or between two different desktops.  Fossil does 
> that, and does so in a much easier fashion than other DVCSes.  (f all sync!)
>
> Dropbox and such are poor alternatives, since I don’t want my object files 
> and executables sync’d to the cloud, and I don’t want to see a throbby little 
> icon in the corner of my vision every time I save a file.  I want to batch my 
> syncs up, do them on my schedule, and send only source files, no object files.

rsync ..
>
> 2. Deduplication.  Your versioning scheme requires needless copies of 
> unchanged files.  Fossil only stores what is needful, which means I can 
> download the entire history of a project without even thinking about it.
>
> I suspect if you checked all the past versions of your system into a single 
> Fossil repo, it would be about the size of 3 or 4 of your existing “whole 
> project” archives.  So, you’ve got a choice: in the same bandwidth/disk space 
> as a handful of archives, you can have all the history, or just the most 
> recent history.
>
> 3. Comments.  I used to keep a paper log book of the things I was working on, 
> so I could go back later and figure out what I did and why.  Searching the 
> comment stream of a Fossil timeline is far better.
>
> 4. Wiki and technotes.  When I have too much to say to fit into a comment 
> box, I can write an article about it, which gets sync’d to my various 
> development machines.
>
> 5. Tickets.  I used to keep a Wishlist or TODO file in each project, 
> containing the things I wanted to do next.  Tickets do that better, since you 
> can prioritize them, search them, reference them from checkin comments and 
> wiki articles, etc.
>
> You can have my Fossil after I *become* a fossil. :)
>
>> Before I start writing a new function, process, or other modification, I 
>> create a sub-folder of my backup folder which are numbered in sequence. The 
>> file system applies a date to the creation time of the folder which 
>> identifies when the backup was made. I then simply copy my entire project 
>> folder into the backup folder.
>
> This is easier than “fossil ci --tag v1.2.3” or “fossil ci --branch 
> expermental-feature”?
>
> For solo projects, branch merging is nearly trivial, since the chances of 
> colliding changes is near-zero.
>
> And if you do find yourself changing the same area of code on two different 
> branches, it’s easy to say something like “f merge trunk” from the branch to 
> sync changes made in the trunk into the experimental branch, so you can 
> overwrite some of the recent trunk changes without confusing Fossil.
>
>> If I break the code, or decide to revert the changes, I restore the project 
>> from the desired backup folder.
>
> That’s easier than “f up trunk” to toss a bad branch, or “f revert” to toss 
> uncommitted changes, or “f up v1.2.3” to roll back to a prior stable version?
>
>> I am finding them just as cumbersome of a process with an added layer of 
>> things to go wrong.
>
> I rarely find Fossil failing in ways I can’t understand.  And every time it 
> has happened, someone on the list has explained it.

But to understand how it failed you have to be familiar with the
concepts of VCS in general and fossil in particular.

Sure VCS commands are no more difficult than filesystem manipulation
commands. The thing is that your project is already in files so you
have to understand the filesystem concept and its manipulation anyway
whereas with a VCS you have to understand new set of concepts,
features, limitations, and commands that give you access to those.
Subtly different for each VCS, no less.

>
> (For instance, my recent thread about how to clip off a a branch via the 
> command line when 

Re: [fossil-users] SHA1 and security

[Scott Robison]

On Oct 29, 2015 6:50 PM, "Warren Young"  wrote:
>
> I also wonder what will happen if someone with an existing checkout
checks in a diff against the changeling file, and the diffs overlap with
the evil bits.  I assume the server will try to apply the patch and fail,
or the next person to clone the repo will get a clone that fails to open.

I don't think fossil transfers deltas via the sync protocol, though my
check of the source code was brief. As i think more about it, fossil can't
really sync delta encoded artifacts because artifacts are unordered, so it
would not be possible to use an artifact if you got it before its
dependency.
___
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] SHA1 and security

[Richard Hipp]

On 10/30/15, Scott Robison  wrote:
>
> I don't think fossil transfers deltas via the sync protocol,

It does.  Most artifacts are transmitted as deltas against existing
artifacts that both ends already know about.

Which reminds me - there is a (non-cryptographic) checksum on every
delta that must also match, thus making it even hard to substitute
foo-evil.c for foo.c.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Why is fossil extras so slow?

[Matt Welland]

time find . -name foo.bar > /dev/null ; time fossil extras > /dev/null;time
find . -name foo.bar > /dev/null ; time fossil extras > /dev/null
0.064u 0.404s 0:03.80 12.1% 0+0k 0+0io 0pf+0w# find
0.204u 1.160s 0:13.03 10.4% 0+0k 0+104io 0pf+0w  # fossil extras
0.032u 0.288s 0:02.25 13.7% 0+0k 0+0io 0pf+0w# find
0.200u 1.208s 0:14.34 9.7%  0+0k 0+104io 0pf+0w  # fossil extras

BTW, git is *faster* than the find command. Is there a configuration that
affects the extras behaviour?
___
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] Why is fossil extras so slow?

[Stephan Beal]

On Fri, Oct 30, 2015 at 8:11 PM, Matt Welland 
wrote:

> time find . -name foo.bar > /dev/null ; time fossil extras >
> /dev/null;time find . -name foo.bar > /dev/null ; time fossil extras >
> /dev/null
> 0.064u 0.404s 0:03.80 12.1% 0+0k 0+0io 0pf+0w# find
> 0.204u 1.160s 0:13.03 10.4% 0+0k 0+104io 0pf+0w  # fossil extras
> 0.032u 0.288s 0:02.25 13.7% 0+0k 0+0io 0pf+0w# find
> 0.200u 1.208s 0:14.34 9.7%  0+0k 0+104io 0pf+0w  # fossil extras
>


Possibly (though speculating - haven't checked the code) because for every
file it has to check the DB to see if it's really an extra or not?


> BTW, git is *faster* than the find command.
>

which is truly strange.

-- 
- 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] xkcd on git

[Stephan Beal]

On Fri, Oct 30, 2015 at 6:05 PM, Eric Rubin-Smith  wrote:

> I suspect Fossil folks will appreciate this :-)
>
> http://xkcd.com/1597/
>
>
http://fossil-scm.org/index.html/info/227b837a6c686972

:)


-- 
- 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] xkcd on git

[Eric Rubin-Smith]

I suspect Fossil folks will appreciate this :-)

http://xkcd.com/1597/

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

[fossil-users] SHA-1 in user.pw field

[Warren Young]

The current stored password algorithm hashes the user’s cleartext password, the 
project code, and the user name with SHA-1.  This will defeat a rainbow table, 
but it means the security of this scheme relies solely on the complexity of 
executing a preimage attack.

Today such an attack would cost about $700k, assuming you’re using publicly 
known techniques:

  https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

Maybe others have better techniques.

Are there Fossil passwords worth that much?  I think so, and the cost is 
continually falling.

Replacing SHA-1 with $BetterHash would help, but to execute such an attack, you 
have to have access to the Fossil server.  If you have that, I don’t see why it 
isn’t less work to just replace the Fossil binary with one that invalidates all 
cookies and saves the plaintext password from the HTTP login transaction 
somewhere.

There are algorithms that allow the server to verify a password without storing 
either it or its hash, and which do not require that the password be 
transmitted in plaintext:

 http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
 
https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism

There are C and JavaScript implementations of both protocols, readily found 
with a search engine.

That’s as much as I know about this.  I have not tried to implement either one.

I’m purposely not covering HTTPS here since the attack requires local access to 
the server, so HTTPS doesn’t help.  That said, SRP and SCRAM remove the need to 
use HTTPS in the first place, at least for maintaining password security in the 
face of a MITM attack.  You should still use HTTPS, though, since a MITM could 
substitute bad deltas into a checkin, for example.
___
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] SHA-1 in user.pw field

[Scott Robison]

On Fri, Oct 30, 2015 at 3:02 PM, Warren Young  wrote:

> The current stored password algorithm hashes the user’s cleartext
> password, the project code, and the user name with SHA-1.  This will defeat
> a rainbow table, but it means the security of this scheme relies solely on
> the complexity of executing a preimage attack.
>
> Today such an attack would cost about $700k, assuming you’re using
> publicly known techniques:
>
>   https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
>
> Maybe others have better techniques.
>
> Are there Fossil passwords worth that much?  I think so, and the cost is
> continually falling.
>
> Replacing SHA-1 with $BetterHash would help, but to execute such an
> attack, you have to have access to the Fossil server.  If you have that, I
> don’t see why it isn’t less work to just replace the Fossil binary with one
> that invalidates all cookies and saves the plaintext password from the HTTP
> login transaction somewhere.
>
> There are algorithms that allow the server to verify a password without
> storing either it or its hash, and which do not require that the password
> be transmitted in plaintext:
>
>  http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
>
> https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
>
> There are C and JavaScript implementations of both protocols, readily
> found with a search engine.
>
> That’s as much as I know about this.  I have not tried to implement either
> one.
>
> I’m purposely not covering HTTPS here since the attack requires local
> access to the server, so HTTPS doesn’t help.  That said, SRP and SCRAM
> remove the need to use HTTPS in the first place, at least for maintaining
> password security in the face of a MITM attack.  You should still use
> HTTPS, though, since a MITM could substitute bad deltas into a checkin, for
> example.
>

I think this is a more reasonable example of how SHA1 is used in a security
context, and why it might be desirable to change it. Still, it is only
there to control remote access to the repo. Once you have access to the
actual repository file (as you observe) all bets are off. This is similar
to how user and group permissions only work until someone pulls a drive
from a computer and completely circumvents the operating system's access
control mechanisms. Doesn't matter how the password file hashes are
generated if no one needs to look at them to gain access to all files.

In the case of an OS enforcing protections to files, it is possible to
apply encryption to the data so that the operating system only decrypts
data on demand. This isn't perfect, and unfortunately, the point to a DVCS
is to share the data with anyone who has access (assuming the access is
permitted and not fraudulently obtained). Encrypting the data isn't really
an option in this case.

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

Re: [fossil-users] xkcd on git

[Gour]

On Pet, 2015-10-30 at 21:33 +0300, Konstantin Khomoutov wrote:

> I'm a programmer, and after having used a bunch of centralized and
> distributed VC systems I've come to a temporary conclusion that the
> set of problems [D]VC systems are trying to solve has certain
> irreducible complexity, and hence these systems either throw it onto
> the heads of the users (Git) or sweep it under the rug (Mercurial,
> Fossil).

I do use Fossil for *all* my private projects and intend to use it for
open-source one as well...however, in my experience using different
(D)VCS, I still believe that Darcs was the easiest one to use, but, it
had some peformance problems as well as lack of reliable public
hosting.


Sincerely,
Gour

-- 
Many, many births both you and I have passed. I can remember 
all of them, but you cannot, O subduer of the enemy!


___
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] xkcd on git

[Scott Doctor]

It is sort of the "Lightbulb Problem":

Scenario 1: I want to design a lightbulb. So I study metallurgy, 
thermodynamics, electronics, manufacturing processes... Study 
what others succeded/failed at,... and so forth.


Scenario 2: I want to use that lightbulb in my project. I only 
need to study a subset, or simply how to wire it up from the manual.


Sceanario 3: I want to turn on the light bulb.


Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 11:44 AM, Gour wrote:

On Pet, 2015-10-30 at 21:33 +0300, Konstantin Khomoutov wrote:


I'm a programmer, and after having used a bunch of centralized and
distributed VC systems I've come to a temporary conclusion that the
set of problems [D]VC systems are trying to solve has certain
irreducible complexity, and hence these systems either throw it onto
the heads of the users (Git) or sweep it under the rug (Mercurial,
Fossil).

I do use Fossil for *all* my private projects and intend to use it for
open-source one as well...however, in my experience using different
(D)VCS, I still believe that Darcs was the easiest one to use, but, it
had some peformance problems as well as lack of reliable public
hosting.


Sincerely,
Gour



___
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] xkcd on git

[Scott Doctor]

That is my experience with all VCS systems. Even with fossil, I 
am having trouble justifying why the hassle is worth the effort.



Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 10:07 AM, Stephan Beal wrote:
On Fri, Oct 30, 2015 at 6:05 PM, Eric Rubin-Smith 
> wrote:


I suspect Fossil folks will appreciate this :-)

http://xkcd.com/1597/


http://fossil-scm.org/index.html/info/227b837a6c686972

:)

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

Re: [fossil-users] xkcd on git

[Konstantin Khomoutov]

On Fri, 30 Oct 2015 10:56:48 -0700
Scott Doctor  wrote:

> That is my experience with all VCS systems. Even with fossil, I 
> am having trouble justifying why the hassle is worth the effort.

I'm honestly not flame-baiting but have you tried to come up with an
interface idea/sketch/set of paradigms that would considerably lower
the barrier for people to use DVC systems?

No, really, even those rare programmers who are able to reason about
the ways their software is used like "mere mortals" are skewed in their
reasoning.

I'm a programmer, and after having used a bunch of centralized and
distributed VC systems I've come to a temporary conclusion that the set
of problems [D]VC systems are trying to solve has certain irreducible
complexity, and hence these systems either throw it onto the heads of
the users (Git) or sweep it under the rug (Mercurial, Fossil).

So it would be really interesting to see some *constructive* discussion
of different approaches such systems should take when making their
users tackle that set of problems.
___
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] xkcd on git

[Richard Hipp]

On 10/30/15, Scott Doctor  wrote:
>
> That is my experience with all VCS systems. Even with fossil, I
> am having trouble justifying why the hassle is worth the effort.
>

What do you do when a customer calls to ask about code you sent them
18 months ago?  How do you figure out what version of the code they
are running?

When you find an obscure bug that you know was not in the release from
December 2012 but might have been introduced anytime between then and
now, how do you figure out when it was introduced?

How do you add experimental features and make experimental changes?
Do you just start hacking away and hope the changes don't break
anything?

How do you identify versions of your code to your customer?

How do you verify that no stray changes have been introduced into your code?

How do you backup your code?

When you have multiple people collaborating on the same project, how
do you coordinate their changes and ensure that features added by one
developer don't get overwritten and erased by another developers.  How
do you know who is working on what?  Can you even identify what you
code is?

Seriously.  I don't understand how it is possible to make reliable
software without good version control.  Is the foundation of
everything.


-- 
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] xkcd on git

[jungle Boogie]

On 30 October 2015 at 10:56, Scott Doctor  wrote:
> That is my experience with all VCS systems. Even with fossil, I am having
> trouble justifying why the hassle is worth the effort.


I version control config files for apps, .vimrc files, and small
scripts just so I can see what changes I make between them and for
faster setup on new machines. In my very simple setup, I see clear
benefits of using version control (Fossil and rcs) on these files. I
can't imagine how serious software dev would work without some form of
version control.

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