Re: [fossil-users] Veracity

[Jeff Slutter]

A couple weeks ago I posted about the possibility of a new configuration
setting called something like "allow-binmerge" (default off). If it is
enabled, and there is a gmerge-command set, could Fossil call the
gmerge-command to resolve a binary merge conflict?

I would like to be able to handle merging some [proprietary] binary
files with my own merge tool, but currently Fossil will refuse to call
to gmerge-command when a binary file is involved.


On 10/19/2011 6:42 PM, Richard Hipp wrote:
>
>
> Concur.  Locks are out-of-band for Fossil.  If anybody thinks they
> really, really need locks, I'll be happy to offer them a referral to
> Veracity.
>
> Note that Fossil works just fine with binary files.  Fossil's
> self-hosting repository contains binary files.  (See, for example,
> www.fossil-scm.org/fossil/artifact/590c4da59eb
> )  I keep a
> private repository of all my slide presentations that is almost all
> binary files. 
>
> The only problem with binary files is that you cannot merge them.  If
> you do introduce a fork on a binary file, that fork needs to be
> resolved manually.  Locks do not help this - they do not magically
> enable merging.  Locks just prevent the fork from happening in the
> first place.  But Michael is right - that can be handled by
> administrative back-channels.

___
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] Veracity (was: Fwd: suggestion on fossil)

[Matt Welland]

On Wed, Oct 19, 2011 at 8:46 PM, Mike Meyer  wrote:

> On Wed, 19 Oct 2011 16:24:17 -0700
> Matt Welland  wrote:
>
> > I sent out a description of how I think light weight "locks" could be
> > implemented on top of fossil in a past email. In fact I'm making some
> good
> > progress on implementing what I want in a wrapper around fossil
> (implement
> > locks in addition to some other things). I can look into making the
> wrapper
> > available if anyone is interested.
> >
> > As has been mentioned Locks are really helpful when managing data that
> can't
> > be automatically merged. However the need is not for draconian control
> but
> > more of a semaphore to prevent accidentally changing a binary file at the
> > same time someone else does.
> >
> > A more than adequate lock/semaphore methodology could be implemented on
> top
> > of fossil roughly like the following...
> >
> > files have two flags; lockcontrolled and lockstate
> >
> > User locks file(s): fossil lock file1 file2 ...
> > 1. Write permissions are removed
> > 2. Lockcontrolled flag is set
> > 3. Lockstate is set.
> > 4. Sync
>
> Suggestion: If autosync is not enabled, treat this as an
> error. Override with -force.
>

Good point. However using the wrapper I take over all calls to fossil and
can do what is needed. If building this into fossil itself then the problem
is a bit harder.


> What happens if you find out that someone else has locked the file
> during the sync? Do you then revert all the changes you made and fail?
>

Terminology is a bit clumsy here. The word lock seems to get us in trouble.
This is the model I'm implementing:

termlockcontrolled  lockstate   writeable
--  --  -   -
normal  false   don't care  yes
locked  truetrueno
unlockedtruefalse   yes (only by locker)

Going from normal to locked is the dangerous (as in potentially confusing)
step. That step should be accompanied by an email for all to do a
sync/update before and after.

Going from locked to unlocked for edit is quite safe. The wrapper requests
the unlock from the central repo and either gets it or not. Only if it gets
the unlock does it open up permissions on the file and notify the user. This
is not a distributed action (at least for my wrapper).


> > On check out
> >1. Files locked by others have write perms removed
>
> So the lock is on the file, at all revisions? Are the same file on
> different branches considered different files in this case?
>

The way I'm implementing it a path/file will be locked/unlocked for all
branches and revisions. Of course this is not a big brother system, users
are free to override and screw the other folks on the team. Such moves might
be career limiting of course since they have enough information to do the
right thing and a record is available as to what really happened.


> > On commit
> >1. Changed locked files cause an error, override with -force
> >
> > On update
> >1. Update write permissions per the flags.
> >2. A locally changed locked file causes a merge failure
>
> If locks aren't specific to a revision, shouldn't this happen on a
> pull (or the pull part of a sync) and not an update?
>

Yes, you are right. Keep in mind that I'm cheating in all this by keeping
the lock data in a separate sqlite3 db and can manage the locks on every
call to fossil. Doing the right thing as part of fossil itself would be a
bit harder I think.


> > On unlock for edit
> >1. If file not already locked
> >2. Update flags, sync
> >3. Open permissions
> >
> > Or something like that. I think the closely coupled agressive sync model
> > fostered by fossil makes this very doable.
>
> So long as you've got either one central server, or a collection of
> very tightly synchronized servers, it should help a lot. Here, tightly
> synchronized means "synchronized much more frequently than pushes come
> in from developers."
>

Yes, very true.


> Personally, I still think this is a lot of work to go through to adopt
> one tool for a job that other tools are designed to do. Sort of like
> building a claw hammer fitting for a screwdriver.
>

Good point. In fact we are using two systems in parallel for this very
reason fossil and another system with rigorous locking. Using the wrapper
for locking is really an experiment I'm doing on my own time that may well
not pan out.


 --
> Mike Meyer   http://www.mired.org/
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailma

Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil)

[Mike Meyer]

On Wed, 19 Oct 2011 16:24:17 -0700
Matt Welland  wrote:

> I sent out a description of how I think light weight "locks" could be
> implemented on top of fossil in a past email. In fact I'm making some good
> progress on implementing what I want in a wrapper around fossil (implement
> locks in addition to some other things). I can look into making the wrapper
> available if anyone is interested.
> 
> As has been mentioned Locks are really helpful when managing data that can't
> be automatically merged. However the need is not for draconian control but
> more of a semaphore to prevent accidentally changing a binary file at the
> same time someone else does.
> 
> A more than adequate lock/semaphore methodology could be implemented on top
> of fossil roughly like the following...
> 
> files have two flags; lockcontrolled and lockstate
> 
> User locks file(s): fossil lock file1 file2 ...
> 1. Write permissions are removed
> 2. Lockcontrolled flag is set
> 3. Lockstate is set.
> 4. Sync

Suggestion: If autosync is not enabled, treat this as an
error. Override with -force.

What happens if you find out that someone else has locked the file
during the sync? Do you then revert all the changes you made and fail?

> On check out
>1. Files locked by others have write perms removed

So the lock is on the file, at all revisions? Are the same file on
different branches considered different files in this case?

> On commit
>1. Changed locked files cause an error, override with -force
>
> On update
>1. Update write permissions per the flags.
>2. A locally changed locked file causes a merge failure

If locks aren't specific to a revision, shouldn't this happen on a
pull (or the pull part of a sync) and not an update?

> On unlock for edit
>1. If file not already locked
>2. Update flags, sync
>3. Open permissions
>
> Or something like that. I think the closely coupled agressive sync model
> fostered by fossil makes this very doable.

So long as you've got either one central server, or a collection of
very tightly synchronized servers, it should help a lot. Here, tightly
synchronized means "synchronized much more frequently than pushes come
in from developers."

Personally, I still think this is a lot of work to go through to adopt
one tool for a job that other tools are designed to do. Sort of like
building a claw hammer fitting for a screwdriver.

  http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.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] Veracity (was: Fwd: suggestion on fossil)

[Matt Welland]

On Wed, Oct 19, 2011 at 4:28 PM, Michael Barrow  wrote:

> I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a
> plane (without wifi, of course) and I want to edit a binary file, I'd be
> hosed because I wouldn't be able to push the lock to the "central" server.
>

Sure it would help a little. If the files were previously locked then you
*know* you are taking a risk making changes that may have to be discarded or
tediously manually merged. If you knew you were likely to edit the files on
the plane then mark them for edit while you still have Wifi at the airport.
Then when your coworker goes to open them she will see that you have taken
the edit lock and will know it is best to wait. Simple, clean and workable
with fossil thanks to the (brilliant) autosync methodology.

As described in another thread they are similar to a tag but at a file
granularity and with the side effect of changing the write permission on the
file. Again, lock is too strong a word. Think semaphore. You are just trying
to make it easier for people to know who is working on what without a mass
of tiresome one line emails such as "don't edit the schematics today!"


> What if, like the Fossil main repo for example, there are two central
> servers?
>

Tags are synced between the two servers just fine right?


> I do like your approach of a wrapper so that crazy lock stuff doesn't
> destroy the pristine awesomeness of Fossil itself. :-)
>

Agreed :)


>
> On Wed, Oct 19, 2011 at 4:24 PM, Matt Welland  wrote:
>
>> I sent out a description of how I think light weight "locks" could be
>> implemented on top of fossil in a past email. In fact I'm making some good
>> progress on implementing what I want in a wrapper around fossil (implement
>> locks in addition to some other things). I can look into making the wrapper
>> available if anyone is interested.
>>
>> As has been mentioned Locks are really helpful when managing data that
>> can't be automatically merged. However the need is not for draconian control
>> but more of a semaphore to prevent accidentally changing a binary file at
>> the same time someone else does.
>>
>> A more than adequate lock/semaphore methodology could be implemented on
>> top of fossil roughly like the following...
>>
>> files have two flags; lockcontrolled and lockstate
>>
>> User locks file(s): fossil lock file1 file2 ...
>> 1. Write permissions are removed
>> 2. Lockcontrolled flag is set
>> 3. Lockstate is set.
>> 4. Sync
>>
>> On check out
>>1. Files locked by others have write perms removed
>>
>> On commit
>>1. Changed locked files cause an error, override with -force
>>
>> On update
>>1. Update write permissions per the flags.
>>2. A locally changed locked file causes a merge failure
>>
>> On unlock for edit
>>1. If file not already locked
>>2. Update flags, sync
>>3. Open permissions
>>
>> Or something like that. I think the closely coupled agressive sync model
>> fostered by fossil makes this very doable.
>>
>> Matt
>> -=-
>>
>> On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal wrote:
>>
>>> On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal wrote:
>>>
 On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski <
 l...@maxnet.org.pl> wrote:

>
> I seem to be still in the 80's... So how do you cope with edit
> conflicts on binary files today?
>

 i wasn't aware that people use them for binary files. i don't ever keep
 binary files in SCM, so i've never had that use case.

>>>
>>> Could a new "special" tag be used to implement lock-like behaviour? By
>>> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).
>>>
>>> --
>>> - stephan beal
>>> http://wanderinghorse.net/home/stephan/
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Michael Barrow
> michael at barrow dot me
> +1 (408) 782-4249
>
>
> ___
> 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] Veracity (was: Fwd: suggestion on fossil)

[Stephan Beal]

On Thu, Oct 20, 2011 at 1:45 AM, Joerg Sonnenberger  wrote:

> On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote:
> > The only problem with binary files is that you cannot merge them.
>
> ...moment. A merge program could extract the zip archive, do a *textual*
> merge on the XML files and zip the result up again. It works well for
> many use cases.


Yes, but with "you", Richard meant "fossil, generically." Any binary merge
requires format-specific info which fossil cannot know.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Veracity (was: Fwd: suggestion on fossil)

[Joerg Sonnenberger]

On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote:
> The only problem with binary files is that you cannot merge them.

Even that is not necessarily true. You can't merge binary files like
text files -- sure. But it doesn't mean that for a specific binary
format, a merge algorithm isn't possible. Consider ODF documents for a
moment. A merge program could extract the zip archive, do a *textual*
merge on the XML files and zip the result up again. It works well for
many use cases.

Joerg
___
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] Adding Fossil to Windows Explorer context menu?

[Gilles]

On Wed, 19 Oct 2011 11:22:38 -0400, Tomek Kott
 wrote:
>For windows users, there is already an effort to get fossil extended to the
>explorer context menu.

I think there's a need for a simple group + items that we can simply
use through file managers like Windows Explorer without launching a
full-fledged application.

www.zhacks.com/2010/03/10/edit-7-zip-right-click-shell-context-menu/

Can someone confirm/infirm that a COM DLL is required for a group +
items to be part of Windows' context menu?

___
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] Veracity (was: Fwd: suggestion on fossil)

[Michael Barrow]

I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a
plane (without wifi, of course) and I want to edit a binary file, I'd be
hosed because I wouldn't be able to push the lock to the "central" server.

What if, like the Fossil main repo for example, there are two central
servers?

I do like your approach of a wrapper so that crazy lock stuff doesn't
destroy the pristine awesomeness of Fossil itself. :-)

On Wed, Oct 19, 2011 at 4:24 PM, Matt Welland  wrote:

> I sent out a description of how I think light weight "locks" could be
> implemented on top of fossil in a past email. In fact I'm making some good
> progress on implementing what I want in a wrapper around fossil (implement
> locks in addition to some other things). I can look into making the wrapper
> available if anyone is interested.
>
> As has been mentioned Locks are really helpful when managing data that
> can't be automatically merged. However the need is not for draconian control
> but more of a semaphore to prevent accidentally changing a binary file at
> the same time someone else does.
>
> A more than adequate lock/semaphore methodology could be implemented on top
> of fossil roughly like the following...
>
> files have two flags; lockcontrolled and lockstate
>
> User locks file(s): fossil lock file1 file2 ...
> 1. Write permissions are removed
> 2. Lockcontrolled flag is set
> 3. Lockstate is set.
> 4. Sync
>
> On check out
>1. Files locked by others have write perms removed
>
> On commit
>1. Changed locked files cause an error, override with -force
>
> On update
>1. Update write permissions per the flags.
>2. A locally changed locked file causes a merge failure
>
> On unlock for edit
>1. If file not already locked
>2. Update flags, sync
>3. Open permissions
>
> Or something like that. I think the closely coupled agressive sync model
> fostered by fossil makes this very doable.
>
> Matt
> -=-
>
> On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal wrote:
>
>> On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal wrote:
>>
>>> On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski <
>>> l...@maxnet.org.pl> wrote:
>>>

 I seem to be still in the 80's... So how do you cope with edit conflicts
 on binary files today?

>>>
>>> i wasn't aware that people use them for binary files. i don't ever keep
>>> binary files in SCM, so i've never had that use case.
>>>
>>
>> Could a new "special" tag be used to implement lock-like behaviour? By
>> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).
>>
>> --
>> - stephan beal
>> http://wanderinghorse.net/home/stephan/
>>
>> ___
>> 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
>
>


-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] Veracity (was: Fwd: suggestion on fossil)

[Matt Welland]

I sent out a description of how I think light weight "locks" could be
implemented on top of fossil in a past email. In fact I'm making some good
progress on implementing what I want in a wrapper around fossil (implement
locks in addition to some other things). I can look into making the wrapper
available if anyone is interested.

As has been mentioned Locks are really helpful when managing data that can't
be automatically merged. However the need is not for draconian control but
more of a semaphore to prevent accidentally changing a binary file at the
same time someone else does.

A more than adequate lock/semaphore methodology could be implemented on top
of fossil roughly like the following...

files have two flags; lockcontrolled and lockstate

User locks file(s): fossil lock file1 file2 ...
1. Write permissions are removed
2. Lockcontrolled flag is set
3. Lockstate is set.
4. Sync

On check out
   1. Files locked by others have write perms removed

On commit
   1. Changed locked files cause an error, override with -force

On update
   1. Update write permissions per the flags.
   2. A locally changed locked file causes a merge failure

On unlock for edit
   1. If file not already locked
   2. Update flags, sync
   3. Open permissions

Or something like that. I think the closely coupled agressive sync model
fostered by fossil makes this very doable.

Matt
-=-

On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal  wrote:

> On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal wrote:
>
>> On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski <
>> l...@maxnet.org.pl> wrote:
>>
>>>
>>> I seem to be still in the 80's... So how do you cope with edit conflicts
>>> on binary files today?
>>>
>>
>> i wasn't aware that people use them for binary files. i don't ever keep
>> binary files in SCM, so i've never had that use case.
>>
>
> Could a new "special" tag be used to implement lock-like behaviour? By
> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
>
> ___
> 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] Veracity (was: Fwd: suggestion on fossil)

[Richard Hipp]

On Wed, Oct 19, 2011 at 6:17 PM, Michael Barrow  wrote:

> No -- please no locks!
>


Concur.  Locks are out-of-band for Fossil.  If anybody thinks they really,
really need locks, I'll be happy to offer them a referral to Veracity.

Note that Fossil works just fine with binary files.  Fossil's self-hosting
repository contains binary files.  (See, for example,
www.fossil-scm.org/fossil/artifact/590c4da59eb)  I keep a private repository
of all my slide presentations that is almost all binary files.

The only problem with binary files is that you cannot merge them.  If you do
introduce a fork on a binary file, that fork needs to be resolved manually.
Locks do not help this - they do not magically enable merging.  Locks just
prevent the fork from happening in the first place.  But Michael is right -
that can be handled by administrative back-channels.

-- 
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] Veracity (was: Fwd: suggestion on fossil)

[Michael Barrow]

No -- please no locks! Remember, you are still free to use out-of-band
mechanisms to contact the other developers to coordinate your activity:
email, telephone, tweet, smoke signals, carrier pigeons, etc.

On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal  wrote:

> On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal wrote:
>
>> On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski <
>> l...@maxnet.org.pl> wrote:
>>
>>>
>>> I seem to be still in the 80's... So how do you cope with edit conflicts
>>> on binary files today?
>>>
>>
>> i wasn't aware that people use them for binary files. i don't ever keep
>> binary files in SCM, so i've never had that use case.
>>
>
> Could a new "special" tag be used to implement lock-like behaviour? By
> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] Locks (Was: Veracity)

[Konstantin Khomoutov]

On Wed, Oct 19, 2011 at 07:41:56PM +0200, Stephan Beal wrote:

>> That could even help even before fossil having a capability of
>> centraliising locks; the read-only permissions could be enough for
>> the people in a team to decide on the locks.
> Can we do read-only cross-platform (i.e. Windows)?
Microsoft filesystems have support for a special file attribute which
controls whether the file should be considered read-only.  It is
advisory.

___
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] Veracity

[Alek Paunov]

BTW, I just cloned Veracity source using veracity (vv) and realized that 
the repo consists of 13 sqlite DBs (WAL mode) + 1 external BLOB file (+ 
counting number simple sqlite3 files with containing table)


On 19.10.2011 15:39, Lluís Batlle i Rossell wrote:

On Wed, Oct 19, 2011 at 08:18:01AM -0400, Richard Hipp wrote:

-- Forwarded message --
From: Yujianbin

(2) support lock command, http://veracity-scm.org has this command.


As Yujianbin mentions veracity... I saw some videos about veracity. From the web
page, the author seems quite inspired by fossil, but on the presentation about
veracity, he did not mention fossil at all.

http://www.ericsink.com/entries/oscon_2011_video.html

I saw that as a not fair presentation, on that regard.

In any case, I wanted to try veracity, and for example it still lacks
'annotate', which for me is a basic command to have. Not that I like much its
'vv log' result either.

The author also clearly said that veracity 'is not community software', so he is
not going to accept regular contributions as his company develops the product,
but he may accept patches.

Whether to support locks... I think it can help some users, but I don't have use
cases in my day to day.

Regards,
Lluís.
___
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] Zenburn color theme for Fossil

[Stephan Beal]

On Wed, Oct 19, 2011 at 8:01 PM, Rolf Meinecke  wrote:

> > If you need a place to host such a repo, i can get one set up for you.
>
> If someone set up a skin central repo, I'd be happy to contribute the
> zenburn skin.
>

http://fossil.wanderinghorse.net/repos/fossil-skins/

i've set you up as the admin - will send the password off-list. Do whatever
you like with it (including adding other admins).


> >> *bow*
> >
> > Was that an intentional reference to the "dogfood"? ;)
>
> No. Sorry, I don't get it.
>

"bow wow" in EN == "bau wau" auf DE


> "It does not matter how you fall, but how you get up again.
>

i know the literal translation, but it sounded like that might have been the
figurative translation used in the DE version of Batman Begins (the DE
versions often reword certain expressions).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Zenburn color theme for Fossil

[Rolf Meinecke]

Am 19.10.2011 um 19:33 schrieb Stephan Beal:
> On Wed, Oct 19, 2011 at 7:16 PM, Rolf Meinecke  wrote:
> Wouldn't it be sufficient to run one Fossil instance for this purpose?
> Like in "eat your own dogfood"?
> 
> LOL! A skin-demo site could work if the anonymous user had the rights to 
> change the skin. i don't think that will work right now without giving 
> anonymous access to far more stuff (e.g. the css and header editors).

Anyone remember openroot.org  ;-)

But actually I only meant having a central repository for skins. 
Any Fossil user can simply clone and then fiddle around on the local copy. KISS.
Pushing changes or new themes would require having an account on skin central.


> If you need a place to host such a repo, i can get one set up for you.

If someone set up a skin central repo, I'd be happy to contribute the zenburn 
skin.


>> *bow*
> 
> Was that an intentional reference to the "dogfood"? ;)

No. Sorry, I don't get it.


>  Es kommt nicht darauf an wie du fällst. Sondern wie du aufstehst!
> 
> Was that the German translation of Batman's catchphrase in Batman Begins? 
> "What do we do when we fall down? We get back up."

Sort of.

"It does not matter how you fall, but how you get up again.


-rolf




-- 
Sometimes I wonder… Why is that Frisbee getting Larger? …and then it hits me.

___
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] Locks (Was: Veracity)

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 10:50:05AM -0700, Mike Meyer wrote:
> 2011/10/19 Lluís Batlle i Rossell 
> 
> No, I take that back. You could force locking to use a central server model.
> For each repository, you have to set a repository as the "lock server".
> Using "self" or some such would mean "You are the lock sever". The lock
> command could then either handle the lock locally, or request it from a
> remote server. Otherwise, you need a distributed lock manager, which is a
> hard enough problem to warrant it's own project.

That's what I had in mind - establishing a central repository as lock server.
Nothing more.
___
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] Locks (Was: Veracity)

[Mike Meyer]

2011/10/19 Lluís Batlle i Rossell 

> On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote:
> > This requires a lot of work on fossils part in order to be reliable.
> If I had to implement that on fossil, I'd use some kind of table like the
> shun
> table, propagated on autosync, that would ban a commit modifying a file.
> 'commit' could have a '--force', that would bypass the locks. I think they
> should be informative, and not restrictive.


> But it's not only locks alone that help, because that would depend on how
> often
> you sync, and you would notice new locks only when syncing, and that would
> be
> already late, because you may have already modified the file in your
> working
> directory, requiring a complex merge.
>

That's what I meant by "a lot of work on fossils part to be reliable."
Whether the lock command fails to create a lock or warns you if someone else
has a lock is immaterial, they both take the same amount of work to figure
out if someone else has a lock. If it isn't reliable, then it doesn't really
solve the problem. And being reliable is a lot of work.

No, I take that back. You could force locking to use a central server model.
For each repository, you have to set a repository as the "lock server".
Using "self" or some such would mean "You are the lock sever". The lock
command could then either handle the lock locally, or request it from a
remote server. Otherwise, you need a distributed lock manager, which is a
hard enough problem to warrant it's own project.


> Svn introduces the property of files of "needs_lock". Those files, once
> checked
> out, are checked out in read-only into disk, and get the writeable state
> only if
> properly got a lock. Of course read-only-ness can be bypassed by the user
> owning
> the file, and that also has only an informative role. Maybe something like
> propagated tags could mark files as needs_lock, and act accordingly on
> updates/checkouts/...
>

SVN has a central server, thus avoiding the hard problem. Once you've got
that, "needs_lock" is a good idea for a SCM that uses a change/commit
workflow instead of the checkout/change/commit workflow.

   ___
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] Locks (Was: Veracity)

[Stephan Beal]

2011/10/19 Lluís Batlle i Rossell 

> Well, the tags name or value could have the file name.
>

That's an idea. But we would also need the branch, wouldn't we? Or does the
tag follow the branch?


> Maybe, instead of tags, there could be a list like the versionable
> 'glob-ignore', of files that require locks. Those could be checked out with
> read-only permissions.
>

That sounds reasonably simple to implement and is probably flexible enough
to handle most cases (where people have either a few binary files of
different types or large collections which all match a wildcard or two).


> That could even help even before fossil having a capability of
> centraliising
> locks; the read-only permissions could be enough for the people in a team
> to
> decide on the locks.
>

Can we do read-only cross-platform (i.e. Windows)?

But the needs-lock tag also has the sync problem - the tag would need to be
in place before the checkout. And update would be more complicated because
fossil would have to temporarily overwrite (and potentially revert) the
permissions in order to perform an update. Hmmm.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Locks (Was: Veracity)

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 07:27:56PM +0200, Stephan Beal wrote:
> 2011/10/19 Lluís Batlle i Rossell 
> 
> > the file, and that also has only an informative role. Maybe something like
> > propagated tags could mark files as needs_lock, and act accordingly on
> > updates/checkouts/...
> >
> 
> You found another use for propagating tags ;).
> 
> As someone pointed out the original thread, fossil currently only allows
> tagging of commits, not files. Looking at the tagxref table, it's not clear
> to me whether that table supports (at least in principal) tagging individual
> files. If it does, tagging sounds like a good and simple solution to the
> "advisory locking" problem.

Well, the tags name or value could have the file name.

Maybe, instead of tags, there could be a list like the versionable
'glob-ignore', of files that require locks. Those could be checked out with
read-only permissions.

That could even help even before fossil having a capability of centraliising
locks; the read-only permissions could be enough for the people in a team to
decide on the locks.

Regards,
Lluís.
___
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] Zenburn color theme for Fossil

[Stephan Beal]

On Wed, Oct 19, 2011 at 7:16 PM, Rolf Meinecke  wrote:

> Wouldn't it be sufficient to run one Fossil instance for this purpose?
> Like in "eat your own dogfood"?
>

LOL! A skin-demo site could work if the anonymous user had the rights to
change the skin. i don't think that will work right now without giving
anonymous access to far more stuff (e.g. the css and header editors).
Perhaps we could add a new permission which gives a user access to the
skin-selection page. Doh, but then we have the problem that the skin is
global. We'd need per-login session data to support that (a feature we've
talked about a couple times but have no compelling need for).

Of course "keep you in the zone" does not make a lot of sense for a website.
> I simply like the colorset.
> If we had the skins/themes in a public repository, anyone could fork and
> contribute a high contrast version.
>

If you need a place to host such a repo, i can get one set up for you.

*bow*
>

Was that an intentional reference to the "dogfood"? ;)


> Es kommt nicht darauf an wie du fällst. Sondern wie du aufstehst!
>

Was that the German translation of Batman's catchphrase in Batman Begins?
"What do we do when we fall down? We get back up."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Locks (Was: Veracity)

[Stephan Beal]

2011/10/19 Lluís Batlle i Rossell 

> the file, and that also has only an informative role. Maybe something like
> propagated tags could mark files as needs_lock, and act accordingly on
> updates/checkouts/...
>

You found another use for propagating tags ;).

As someone pointed out the original thread, fossil currently only allows
tagging of commits, not files. Looking at the tagxref table, it's not clear
to me whether that table supports (at least in principal) tagging individual
files. If it does, tagging sounds like a good and simple solution to the
"advisory locking" problem.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Zenburn color theme for Fossil

[Rolf Meinecke]

Hi!

Am 19.10.2011 um 03:10 schrieb Christopher Berardi:
> I think it would be a great idea to have some kind of repository where fossil
> users could share things like color schemes (or possibly extensions some day).
> Something along the lines of gnome-look.org. 

Wouldn't it be sufficient to run one Fossil instance for this purpose?
Like in "eat your own dogfood"?


> Rolf: The theme reminds me of one of the builtin gvim themes (desert?).

I butchered the "Khaki, No Logo." skin that comes with Fossil.


> Visually, I like high contrast between background and text -- yellow, white,
> or green on black, white on blue, etci -- so the peach on grey is a little too
> subtle for my eyes to be comfortable with. But, I know some people who like
> that subtlety.

>From the zenburn readme:
"Zenburn is a low-contrast color scheme for Vim. It’s easy for your eyes and
designed to keep you in the zone for long programming sessions."

Of course "keep you in the zone" does not make a lot of sense for a website. I 
simply like the colorset.
If we had the skins/themes in a public repository, anyone could fork and 
contribute a high contrast version.


> Thanks for sharing.

Thank you all for providing Fossil in the first place!

*bow*

-rolf





— 
Es kommt nicht darauf an wie du fällst. Sondern wie du aufstehst!

___
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] Locks (Was: Veracity)

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote:
> This requires a lot of work on fossils part in order to be reliable. Unlike
> source changes, you can't do a commit and then require a merge before
> pushing if there's a collision. There are also nasty restrictions on how you
> do things. In particular, you have to have autosync on (or ignore it if off)
> and be connected to all repositories you push/pull from to use it.
> 
> Given those restrictions, if you're looking to change things to support
> fossil, wouldn't you be better off using a tool designed for managing
> binaries ( an artifact repository) instead of one designed for managing
> textual sources?

I think fossil is a good tool for managing binaries too. And often binaries and
textual sources better go together in a single repository.

If I had to implement that on fossil, I'd use some kind of table like the shun
table, propagated on autosync, that would ban a commit modifying a file.
'commit' could have a '--force', that would bypass the locks. I think they
should be informative, and not restrictive.

But it's not only locks alone that help, because that would depend on how often
you sync, and you would notice new locks only when syncing, and that would be
already late, because you may have already modified the file in your working
directory, requiring a complex merge.

Svn introduces the property of files of "needs_lock". Those files, once checked
out, are checked out in read-only into disk, and get the writeable state only if
properly got a lock. Of course read-only-ness can be bypassed by the user owning
the file, and that also has only an informative role. Maybe something like
propagated tags could mark files as needs_lock, and act accordingly on
updates/checkouts/...

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

[fossil-users] Locks (Was: Veracity)

[Mike Meyer]

This requires a lot of work on fossils part in order to be reliable. Unlike
source changes, you can't do a commit and then require a merge before
pushing if there's a collision. There are also nasty restrictions on how you
do things. In particular, you have to have autosync on (or ignore it if off)
and be connected to all repositories you push/pull from to use it.

Given those restrictions, if you're looking to change things to support
fossil, wouldn't you be better off using a tool designed for managing
binaries ( an artifact repository) instead of one designed for managing
textual sources?

___
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] Adding Fossil to Windows Explorer context menu?

[Tomek Kott]

For windows users, there is already an effort to get fossil extended to the
explorer context menu. At the moment, the C# library for fossil commands is
being written. See Ingo's "SharpFossil" library implementation for .NET
purposes:
http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil/wiki?name=SharpFossil+Library
.

I think that the library currently has most of the commonly used functions
written, so there might be an opportunity to start coding a explorer
extension using that library.

Just some cents...

Tomek

On Wed, Oct 19, 2011 at 8:59 AM, Gilles  wrote:

> On Wed, 19 Oct 2011 09:33:15 +0200, Kohn Bernhard
>  wrote:
> >thanks for sharing the idea using Fast Explorer. I find it very good!
>
> Actually, it's not that good because...
> - it requires installing Fast Explorer
> - it requires adding a fossil.bat just to call "pause" to keep the DOS
> box open after fossil.exe exits
> - "fossil gdiff --from previous myfile.txt" doesn't work because "%1%"
> returns the full path
> - the gdiff above is called for All Files, which means that this item
> is not displayed in the Fossil group like the other items
>
> I haven't found how to add a group + items in the context menu à la
> 7zip. It seems like we must write a COM DLL for this.
>
> >For my personal use I have written a small .net program FossilCmd for
> opening a windows command console and sending fossil commands to it.
>
> Sound good. Could you upload it so we can check it out?
>
> Thank you.
>
> ___
> 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] Veracity

[Stephan Beal]

On Wed, Oct 19, 2011 at 5:06 PM, Alaric Snell-Pym
wrote:

> Tags apply to whole commits, though, not individual files. Perhaps
>

Doh, you're right. And it sounded so simple. :/

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Veracity

[Alaric Snell-Pym]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/19/2011 03:52 PM, Stephan Beal wrote:


> Could a new "special" tag be used to implement lock-like behaviour? By
> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).

Tags apply to whole commits, though, not individual files. Perhaps
lock/unlock actions should be implemented as a special commit that
changes no file data, but changes a "locked by " property of the
files in the manifest. Making them slightly funny commits would mean
they appear in the history and are appropriately replicated, scoped to
branches, and all that jazz.

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6e54UACgkQRgz/WHNxCGoJpACcCb2CEFRnyD3QFLJF6cBqLpGm
UHUAn2evRfMColj1Bi739+VrlDQXsj5l
=PUux
-END PGP 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] Veracity (was: Fwd: suggestion on fossil)

[Stephan Beal]

On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal  wrote:

> On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski <
> l...@maxnet.org.pl> wrote:
>
>>
>> I seem to be still in the 80's... So how do you cope with edit conflicts
>> on binary files today?
>>
>
> i wasn't aware that people use them for binary files. i don't ever keep
> binary files in SCM, so i've never had that use case.
>

Could a new "special" tag be used to implement lock-like behaviour? By
"special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Veracity (was: Fwd: suggestion on fossil)

[Stephan Beal]

On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski
wrote:

>
> On Oct 19, 2011, at 2:50 PM, Stephan Beal wrote:
> > My 0.02€:  in some 16 years of using source control, i have never once
> had a
> > use for (and sometimes been hindered by) locks. IMO anyone who _thinks_
> they
> > need them is still living in the 1980's or early 1990's.
>

And now i say: "open mouth, insert foot." Because...


> I seem to be still in the 80's... So how do you cope with edit conflicts on
> binary files today?
>

i wasn't aware that people use them for binary files. i don't ever keep
binary files in SCM, so i've never had that use case.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Veracity

[Kevin Greiner]

2011/10/19 Lluís Batlle i Rossell 

>
> I think that the veracity documentation totally deludes. :) But it may be
> intended, as it's a product of sourcegear. Eric wrote a book about it...
> and his
> message is (I think) "buy the book".


Actuallythey're giving the book away. I got a free copy in the mail a
few weeks ago. Haven't read it yet though.

http://www.ericsink.com/vcbe/index.html - look for "request a free copy"
___
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] Veracity (was: Fwd: suggestion on fossil)

[Remigiusz Modrzejewski]

On Oct 19, 2011, at 2:50 PM, Stephan Beal wrote:

> 2011/10/19 Lluís Batlle i Rossell 
> 
>> Whether to support locks... I think it can help some users, but I don't
>> have use
>> cases in my day to day.
>> 
> 
> My 0.02€:  in some 16 years of using source control, i have never once had a
> use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they
> need them is still living in the 1980's or early 1990's.

I seem to be still in the 80's... So how do you cope with edit conflicts on 
binary files today? And yes, this actually happened to me, one of us applied 
some pretty gradients to icons, while the other changed their shape...

Kind regards,
Remigiusz Modrzejewski



___
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] Veracity

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 08:21:55AM -0500, Eric Sink wrote:
> 
> > IMO anyone who
> > _thinks_ they need them is still living
> > in the 1980's or early 1990's.
> 
> Tell that to the gaming companies.  They use version control,
> and their repositories contain large numbers of very large
> binary files (images).  The absence of locks in the DVCS world
> is the main reason they can't really consider getting off
> Perforce.
> 
> The ONLY reason Veracity has locks is for this use case.

People use DVCS not only in the scenarios of
lost-connection-to-a-central-server. Here, most of the time, we have a
connection to it. fossil autosync is also related to that.

Having locks helps a lot managing binary files in a team, I'm sure of that. And
having DVCS implementing them so they work well in the connected-to-the-server
scenario sounds very good.

I just did not have the need of them, but I might some day.
___
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] Veracity

[Dmitry Chestnykh]

On Wed, 19 Oct 2011 14:56:47 +0200 Stephan Beal 
wrote:

> So the master plan is to create an SCM for the sole purpose of
> selling books about the SCM (whose sole purpose is to sell a book
> about...)?

Actually, Eric gave away this book ;-)

-- 
Dmitry Chestnykh
http://www.codingrobots.com
___
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] Veracity

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 08:26:23AM -0500, Eric Sink wrote:
 
> You can get the book in HTML, PDF or EPUB here:
> 
> http://www.ericsink.com/vcbe/

I was sure you were in this list ;)
Thank you for the link!

> On 10/19/11 7:56 AM, Stephan Beal wrote:
> >2011/10/19 Lluís Batlle i Rossell  >>
> >
> >I think that the veracity documentation totally deludes. :) But it
> >may be
> >intended, as it's a product of sourcegear. Eric wrote a book about
> >it... and his
> >message is (I think) "buy the book".
> >
> >
> >So the master plan is to create an SCM for the sole purpose of selling
> >books about the SCM (whose sole purpose is to sell a book about...)?
> >
> >;)
> >
> >--
> >- stephan beal
> >http://wanderinghorse.net/home/stephan/
> >
> >
> >___
> >fossil-users mailing list
> >fossil-users@lists.fossil-scm.org
> >http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil)

[Dmitry Chestnykh]

On Wed, 19 Oct 2011 14:50:26 +0200 Stephan Beal 
wrote:

> My 0.02€:  in some 16 years of using source control, i have never
> once had a use for (and sometimes been hindered by) locks. IMO anyone
> who _thinks_ they need them is still living in the 1980's or early
> 1990's.

Just for fun: a lock sitting in FVWM CVS repository since 2008:
http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15603.html

-- 
Dmitry Chestnykh
http://www.codingrobots.com
___
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] Veracity

[Eric Sink]

Er, no.  The book is free.

I mean actually, er, free.  In both electronic and paper forms.

You can get the book in HTML, PDF or EPUB here:

http://www.ericsink.com/vcbe/

The paper version is 288 pages in full color.  We've shipped
out over 13,000 copies, including free postage, to people all
over the world.

--
E


On 10/19/11 7:56 AM, Stephan Beal wrote:

2011/10/19 Lluís Batlle i Rossell mailto:virik...@gmail.com>>

I think that the veracity documentation totally deludes. :) But it
may be
intended, as it's a product of sourcegear. Eric wrote a book about
it... and his
message is (I think) "buy the book".


So the master plan is to create an SCM for the sole purpose of selling
books about the SCM (whose sole purpose is to sell a book about...)?

;)

--
- stephan beal
http://wanderinghorse.net/home/stephan/


___
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] Veracity

[Eric Sink]

> IMO anyone who
> _thinks_ they need them is still living
> in the 1980's or early 1990's.

Tell that to the gaming companies.  They use version control,
and their repositories contain large numbers of very large
binary files (images).  The absence of locks in the DVCS world
is the main reason they can't really consider getting off
Perforce.

The ONLY reason Veracity has locks is for this use case.

--
E

On 10/19/11 7:50 AM, Stephan Beal wrote:

2011/10/19 Lluís Batlle i Rossell mailto:virik...@gmail.com>>

Whether to support locks... I think it can help some users, but I
don't have use
cases in my day to day.


My 0.02€:  in some 16 years of using source control, i have never once
had a use for (and sometimes been hindered by) locks. IMO anyone who
_thinks_ they need them is still living in the 1980's or early 1990's.

--
- stephan beal
http://wanderinghorse.net/home/stephan/


___
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] Adding Fossil to Windows Explorer context menu?

[Gilles]

On Wed, 19 Oct 2011 09:33:15 +0200, Kohn Bernhard
 wrote:
>thanks for sharing the idea using Fast Explorer. I find it very good!

Actually, it's not that good because...
- it requires installing Fast Explorer 
- it requires adding a fossil.bat just to call "pause" to keep the DOS
box open after fossil.exe exits
- "fossil gdiff --from previous myfile.txt" doesn't work because "%1%"
returns the full path
- the gdiff above is called for All Files, which means that this item
is not displayed in the Fossil group like the other items

I haven't found how to add a group + items in the context menu à la
7zip. It seems like we must write a COM DLL for this.

>For my personal use I have written a small .net program FossilCmd for opening 
>a windows command console and sending fossil commands to it.

Sound good. Could you upload it so we can check it out?

Thank you.

___
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] Veracity

[Ron Aaron]

Ah, thank you.  Now I understand.  And it looks to me like a big
headache waiting to happen.  Relying on people following "intentions" of
the software is not very robust.

On 10/19/2011 02:55 PM, Lluís Batlle i Rossell wrote:
> On Wed, Oct 19, 2011 at 02:52:41PM +0200, Ron Aaron wrote:
>> And furthermore, how exactly do "locks" work in a distributed SCM
>> context? (that was my 2 NIS)
> http://veracity-scm.com/qa/questions/102/why-would-you-design-a-dvcs-in-2011-that-supports-file-locks-dvcs-are-meant-to-make-it-needless-to-worry-about-that
>
> I think that the veracity documentation totally deludes. :) But it may be
> intended, as it's a product of sourcegear. Eric wrote a book about it... and 
> his
> message is (I think) "buy the book".
>
>> On 10/19/2011 02:50 PM, Stephan Beal wrote:
>>> My 0.02€:  in some 16 years of using source control, i have never once
>>> had a use for (and sometimes been hindered by) locks. IMO anyone who
>>> _thinks_ they need them is still living in the 1980's or early 1990's.
>>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Veracity

[Stephan Beal]

2011/10/19 Lluís Batlle i Rossell 

> I think that the veracity documentation totally deludes. :) But it may be
> intended, as it's a product of sourcegear. Eric wrote a book about it...
> and his
> message is (I think) "buy the book".
>
>
So the master plan is to create an SCM for the sole purpose of selling books
about the SCM (whose sole purpose is to sell a book about...)?

;)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Veracity

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 02:52:41PM +0200, Ron Aaron wrote:
> And furthermore, how exactly do "locks" work in a distributed SCM
> context? (that was my 2 NIS)

http://veracity-scm.com/qa/questions/102/why-would-you-design-a-dvcs-in-2011-that-supports-file-locks-dvcs-are-meant-to-make-it-needless-to-worry-about-that

I think that the veracity documentation totally deludes. :) But it may be
intended, as it's a product of sourcegear. Eric wrote a book about it... and his
message is (I think) "buy the book".

> On 10/19/2011 02:50 PM, Stephan Beal wrote:
> >
> > My 0.02€:  in some 16 years of using source control, i have never once
> > had a use for (and sometimes been hindered by) locks. IMO anyone who
> > _thinks_ they need them is still living in the 1980's or early 1990's.
> >
> ___
> 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] Fwd: suggestion on fossil

[dexen deVries]

On Wednesday 19 of October 2011 14:35:54 Remigiusz Modrzejewski wrote:
> On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote:
> > I have two suggestion on fossil:
> > 
> > (1) support LDAP. It is a essential function for a large enterprise to
> > manage users login and authentication.
> > 
> > (2) support lock command, http://veracity-scm.org has this command.
> 
> My $0.02: both seem to be pretty valid points...

My EUR 0.02: locking creates surprising roadblock once the team grows larger 
(say, >16 developers, or >8 when distributed geographically). At prev 
workplace, locks placed carelessly by colleauges from remote offices caused us 
to miss some deadlines. Of course, it was possible to work 'em around, but it 
took good understaing of VCS & left some mess in revision history.


Why does Veracity tout explicit support for file renames? From what I've seen 
in Git, the implicit rename model is much more robust -- it does not depend on 
human factor -- on remembering to issue the right command when moving files 
around.


-- 
dexen deVries

[[[↓][→]]]

http://xkcd.com/732/
___
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] Veracity

[Ron Aaron]

And furthermore, how exactly do "locks" work in a distributed SCM
context? (that was my 2 NIS)

On 10/19/2011 02:50 PM, Stephan Beal wrote:
>
> My 0.02€:  in some 16 years of using source control, i have never once
> had a use for (and sometimes been hindered by) locks. IMO anyone who
> _thinks_ they need them is still living in the 1980's or early 1990's.
>
___
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] Veracity (was: Fwd: suggestion on fossil)

[Stephan Beal]

2011/10/19 Lluís Batlle i Rossell 

> Whether to support locks... I think it can help some users, but I don't
> have use
> cases in my day to day.
>

My 0.02€:  in some 16 years of using source control, i have never once had a
use for (and sometimes been hindered by) locks. IMO anyone who _thinks_ they
need them is still living in the 1980's or early 1990's.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Veracity (was: Fwd: suggestion on fossil)

[Lluís Batlle i Rossell]

On Wed, Oct 19, 2011 at 08:18:01AM -0400, Richard Hipp wrote:
> -- Forwarded message --
> From: Yujianbin 
> 
> (2) support lock command, http://veracity-scm.org has this command.

As Yujianbin mentions veracity... I saw some videos about veracity. From the web
page, the author seems quite inspired by fossil, but on the presentation about
veracity, he did not mention fossil at all.

http://www.ericsink.com/entries/oscon_2011_video.html

I saw that as a not fair presentation, on that regard.

In any case, I wanted to try veracity, and for example it still lacks
'annotate', which for me is a basic command to have. Not that I like much its
'vv log' result either.

The author also clearly said that veracity 'is not community software', so he is
not going to accept regular contributions as his company develops the product,
but he may accept patches.

Whether to support locks... I think it can help some users, but I don't have use
cases in my day to day.

Regards,
Lluís.
___
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] Fwd: suggestion on fossil

[Remigiusz Modrzejewski]

On Oct 19, 2011, at 2:18 PM, Richard Hipp wrote:

> I have two suggestion on fossil:
> 
> (1) support LDAP. It is a essential function for a large enterprise to
> manage users login and authentication.
> 
> (2) support lock command, http://veracity-scm.org has this command.

My $0.02: both seem to be pretty valid points...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fwd: suggestion on fossil

[Richard Hipp]

-- Forwarded message --
From: Yujianbin 
Date: 2011/10/18
Subject: suggestion on fossil
To: "d...@hwaci.com" 


 Hi, D. Richard Hipp,

** **

I have two suggestion on fossil:

(1) support LDAP. It is a essential function for a large enterprise to
manage users login and authentication.

(2) support lock command, http://veracity-scm.org has this command.

** **
 --

Justin Yu 俞健斌
华为技术有限公司 Huawei Technologies Co., Ltd.
**[image: Company_logo]**
Mobile: +86-13316882199
Email: yujian...@huawei.com
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com 
 --

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from
HUAWEI, which
is intended only for the person or entity whose address is listed above. Any
use of the
information contained herein in any way (including, but not limited to,
total or partial
disclosure, reproduction, or dissemination) by persons other than the
intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!

** **



-- 
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] css-wiki?

[Ron Georgia]

Yay

Ron Georgia
John 13:23
Sent from my iPad (cool)

On Oct 16, 2011, at 8:49 PM, Jan Danielsson  wrote:

> Hello,
> 
>   I'm thinking it might be a good idea to write a wiki-page with a
> short introduction/guide to the CSS editor in fossil, with a chapter
> dedicated to helping users [who don't know CSS and don't care to learn
> it more than they have to] to modify things like the behavior and layout
> of the side-by-side diff. As someone wrote earlier: No matter how you
> do, there will always be those other 50% who want it the other way.
> 
>   Rather than reinvent w3schools.com, it would be more of a guide with
> simple recipes along the line of "To get behavior X, add lines Y to
> section Z".
> 
>   Yay/Nay?
> 
>   Is there a suitable wiki-page for it already, or should I add a css.wiki?
> 
> -- 
> Kind regards,
> Jan Danielsson
> 
> 
> ___
> 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] Adding Fossil to Windows Explorer context menu?

[Kohn Bernhard]

Hi Gilles,

thanks for sharing the idea using Fast Explorer. I find it very good!
For my personal use I have written a small .net program FossilCmd for opening a 
windows command console and sending fossil commands to it.
The windows command console remains open until I close it directly. If there is 
already an open windows command console for this particular working directory, 
the command is send to this window, so there will no cluttering of serval open 
windows command consoles, only one per working directory (this is achieved by 
searching the _FOSSIL_ file in the parent directories).
With the fast explorer I build an explorer menu (only for directories) and call 
the program (e.g. FossilCmd changes %1, where %1 is the directory I selected in 
explorer). This is pretty nice working (just used it for one day).

If this is of any use for others, I can make this public available.

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

[fossil-users] Adding Fossil to Windows Explorer context menu?

[Kohn Bernhard]

Hi Gilles,

thanks for sharing the idea using Fast Explorer. I find it very good!
For my personal use I have written a small .net program FossilCmd for opening a 
windows command console and sending fossil commands to it.
The windows command console remains open until I close it directly. If there is 
already an open windows command console for this particular working directory, 
the command is send to this window, so there will no cluttering of serval open 
windows command consoles, only one per working directory (this is achieved by 
searching the _FOSSIL_ file in the parent directories).
With the fast explorer I build an explorer menu (only for directories) and call 
the program (e.g. FossilCmd changes %1, where %1 is the directory I selected in 
explorer). This is pretty nice working (just used it for one day).

If this is of any use for others, I can make this public available.

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