Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil)
On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote: > 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. I think something similar could be said about other fossil features; any feature is a plus for fossil. You also mentioned some implementation of a checklist. In a good situation, every developer in a repository will know what will be easy to merge and what not, and they should know that they have to speak with the rest of the team to edit that. And then those in the team have to remember that someone is editing that. But in a worse case, this system may fail, and some little infrastructure provided by fossil could be helpful. But, of course, first we should have a great idea to implement. :) I don't know how veracity deals with locks, but I think that they should not only be able to protect against in-branch editions, but also between branches, when there are future merges planned. With a VCS where people do a lot of feature-branches (we use fossil this way here), in-branch locks may be of little help. 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] Veracity (was: Fwd: suggestion on fossil)
On Thu, 20 Oct 2011 17:28:27 +0200 jos van kesteren wrote: [...] >>> 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. [...] > Since ODF documents can be unzipped, and their XML contents are text > anyway, why not make a commit program (instead of a merge program) > that unzips the ODF and > stores the XML in the repo ? Note that there are some problems: 1) Zipping them back is not that trivial [1] which means you have to use specialized "uncommit" program to properly reassemble such containers. 2) ODF container stores several files in several directories, so as soon as you unpacked it, it's not just a single file anymore, so you have to invent a way to somehow treat the files from this container as a single entity when they are stored in a DVCS. (And in some or a parallel thread here someone confirmed Fossil does only tag commits, not files.) 3) The XML files in ODF containers, while human-readable, are still autogenerated. The XML format is indeed intended to increase accessibility of the content, but innocent changes in the document from the point of view of the user who made them can result in rather "interesting" changes in the content files. For instance, ODT (spreadsheets), as far as I know, do not allow you to directly attach a property to a cell which would indicate that cell has red background color; instead the editor will create a special style inculding that color info (unless there's no already existing matching style) and attach it to that cell. By this I'm suggesting that diffing contents of two ODF files using only their unpacked contents could not be that straigforward to comprehend. 1. http://tanguy.ortolo.eu/blog/article24/ ___ 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)
On Thursday 20 of October 2011 17:28:27 jos van kesteren wrote: > Since ODF documents can be unzipped, and their XML contents are text > anyway, why not make a commit program (instead of a merge program) that > unzips the ODF and > stores the XML in the repo ? that assumes merging /text/ of XML of ODF documents can be done in a reliable way. The format seems complex enough to make that error-prone. Same for UML files. -- 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 (was: Fwd: suggestion on fossil)
>> >> Date: Thu, 20 Oct 2011 01:45:30 +0200 >> From: Joerg Sonnenberger >> To: fossil-users@lists.fossil-scm.org >> Subject: Re: [fossil-users] Veracity (was: Fwd: suggestion on fossil) >> Message-ID: <20111019234530.gb10...@britannica.bec.de> >> Content-Type: text/plain; charset=us-ascii >> >> 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 >> Since ODF documents can be unzipped, and their XML contents are text anyway, why not make a commit program (instead of a merge program) that unzips the ODF and stores the XML in the repo ? Jos van Kesteren. ___ 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)
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)
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)
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)
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)
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] Veracity (was: Fwd: suggestion on fossil)
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)
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)
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)
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] Veracity (was: Fwd: suggestion on fossil)
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)
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 (was: Fwd: suggestion on fossil)
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 (was: Fwd: suggestion on fossil)
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 (was: Fwd: suggestion on fossil)
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)
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
