From: Andreas K. <and...@ac...> - 2011-02-14 21:22:34
|
Hi all you developers of Tcllib, Tklib, BWidget, etc. .. You might have noted that the SourceForge CVS was down for two weeks, after a hack attack on them. This downtime ended last week, allowing us, in principle, to continue development and re-start commits. There is however a fly in the soup. Quoting from Jeff's mail to tcl-core In the interim, SF also let us know that cvs is now considered a legacy service. In other words, the end-of-life of CVS repositories on SF, and maybe in general is on the radar now, and it behooves us, IMHO, to do the transition to something else _now_. As such I ask everyone to hold back from commiting anything to any of the projects under tcllib (1) until we have this issue resolved. While SourceForge apparently will offer a migration service from CVS to SVN I agree with Jeff that we should transition to a proper DVCS instead. Related to the choicce of DVCS is also the issue of hosting, i.e. depending on what our choice of system we have less or more options for hosting. Following the discussions on the chat, about the same issue, only for core Tcl/Tk the main contenders are our own Richard Hipp's "fossil" (2), and the ubiquitous 800lb gorilla "git" (3) From a technical point of view both will do the job, and are pretty much equivalent. Conversion to either should be relatively trivial via "cvs2git" (4), both support the fast-export file-format generated by the converter. Non-technical arguments for either are * fossil is small, clean, simple, easy to learn, with the developer part of the Tcl community, and known to be responsive. Pretty much on call. * git, while not small, and with a steep learning curve, however is *ubiquitous*, with a much larger community. Students learn it. Using it means that a GSoC student (for example), can simply be pointed to the git repository and told to branch. * On the hosting front, using git give us lots of alternatives as: SourceForge, github, gitorious(sp?), assembla * For fossil we either have to either use the pretty much unknown chiselapp or self-host. The latter might actually not be to onerous, given that fossil comes with a builtin web server. Just needs a box. * Richard has its own comparison and reasons for either at http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki Do I have my own preference ? Yes. And I sincerely hope that I managed to keep it out of the arguments above. One last issue. As (1) shows, we have lots of subprojects. Seven. While these are all handled by a single CVS repository directory hierarchy, when going to DVCS we should really split them up, each as their own XXX repository. One of them, tclbench, should possibly even migrate out of the tcllib more to the core itself, given that it is the core whose performance this project is testing. Discussion is open. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) Which are bwidget mclistbox tclapps tclbench tcllib (sic) tklib widget (2) http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki (3) http://www.kernel.org/pub/software/scm/git/docs/git.html (4) In contrast to Tcl/Tk core tcllib does not have vendor branches in the history AFAIK. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Lars H. <Lar...@re...> - 2011-02-14 23:10:32
|
Andreas Kupries skrev 2011-02-14 22.21: > * fossil is small, clean, simple, easy to learn, [snip] > * git, while not small, and with a steep learning curve, Hmm... I have to say I find those claims somewhat contrary to own experience, although I cannot claim that this experience would constitute a comprehensive survey of both systems. In particular: * IMHO git both seems fairly small and wasn't too hard to learn. (Once I got past the slightly scary step that one was supposed to use git to download the manpages for git.) * Fossil having tickets, wiki, and blog built in doesn't strike me as clean (possibly convenient, if you want those features, but not clean), and should pose a challenge to being small. But perhaps the comparison is with git + 3rd party tools for tickets, wiki, and blog. * The web interface to Fossil regularly strikes me as being awkward, at least when one encounters it as an outsider (which is not a use-case that should be ignored); the requirement to log in as anonymous to access certain information is particularly discouraging. It may seem more natural for registered users, however. > * Richard has its own comparison and reasons for either at > http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki That does take a rather "databases are where it's at" view of the matter, which is not surprising given DRH's area of expertise, but in some cases I find myself wondering how deep the analysis is that underlies his evaluation of git. In particular the points about immutability and pile-of-files seem open to interpretation; git does have immutability, but it is local rather than the global immutability fossil appears to set as standard. The "git uses pile-of-files, hence it is transactionally unsafe" point in that summary /may/ be based on discovering a proper vulnerability in git, but I /fear/ it could rather be based on a failure to understand that local immutability suffices for the wanted transactional safety. I would appreciate it if DRH can lay that fear to rest, however. > Do I have my own preference ? Yes. And I sincerely hope that I managed to keep > it out of the arguments above. Well, if your intent was to not show your own preferrence, then you probably failed. :-) Lars Hellström |
From: Will D. <wi...@wj...> - 2011-02-15 00:32:59
|
Lars, Provable immutability is one of Fossil's requirements; in the development arena that Richard was (and might still be) targetting, it was required that a file with a given revision UUID could simply not be changed. You can read more about that at the fossil website. This is not a requirement for most users. In short, I don't think Richard is saying that git is substandard in this area, but rather that Fossil provides a stronger form of immutability if you happen to need that. Will On Feb 14, 2011, at 3:10 PM, Lars Hellström wrote: > Andreas Kupries skrev 2011-02-14 22.21: >> * fossil is small, clean, simple, easy to learn, > [snip] >> * git, while not small, and with a steep learning curve, > > Hmm... I have to say I find those claims somewhat contrary to own experience, > although I cannot claim that this experience would constitute a comprehensive > survey of both systems. In particular: > > * IMHO git both seems fairly small and wasn't too hard to learn. > (Once I got past the slightly scary step that one was supposed to > use git to download the manpages for git.) > > * Fossil having tickets, wiki, and blog built in doesn't strike me as > clean (possibly convenient, if you want those features, but not clean), > and should pose a challenge to being small. But perhaps the comparison > is with git + 3rd party tools for tickets, wiki, and blog. > > * The web interface to Fossil regularly strikes me as being awkward, > at least when one encounters it as an outsider (which is not a use-case > that should be ignored); the requirement to log in as anonymous to > access certain information is particularly discouraging. It may seem > more natural for registered users, however. > >> * Richard has its own comparison and reasons for either at >> http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki > > That does take a rather "databases are where it's at" view of the matter, > which is not surprising given DRH's area of expertise, but in some cases I > find myself wondering how deep the analysis is that underlies his evaluation > of git. In particular the points about immutability and pile-of-files seem > open to interpretation; git does have immutability, but it is local rather > than the global immutability fossil appears to set as standard. The "git uses > pile-of-files, hence it is transactionally unsafe" point in that summary > /may/ be based on discovering a proper vulnerability in git, but I /fear/ it > could rather be based on a failure to understand that local immutability > suffices for the wanted transactional safety. I would appreciate it if DRH > can lay that fear to rest, however. > >> Do I have my own preference ? Yes. And I sincerely hope that I managed to keep >> it out of the arguments above. > > Well, if your intent was to not show your own preferrence, then you probably > failed. :-) > > Lars Hellström > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Tcllib-devel mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcllib-devel Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog |
From: Lars H. <Lar...@re...> - 2011-02-16 13:45:26
|
Will Duquette skrev 2011-02-15 01.32: > Lars, > > Provable immutability is one of Fossil's requirements; in the development > arena that Richard was (and might still be) targetting, it was required that > a file with a given revision UUID could simply not be changed. But that's true for git too! The rebase command *cannot* change the data in an existing commit. It creates a new commit, which frequently has the same contents (tree) as the original, but since it has a different history it will also have a different ID. > You can read > more about that at the fossil website. This is not a requirement for most > users. In short, I don't think Richard is saying that git is substandard in > this area, but rather that Fossil provides a stronger form of immutability if > you happen to need that. The point where I fear Richard is making an unfounded claim is rather the point before, where he says "Single file database (fossil): good, safe. Pile of files on disk like git: bad, unsafe." The thing he worries about seems to be corruption of data due to interrupted updates of it (and as a database expert, it is his job to be concerned about this). However, because of the immutability of objects (blobs, trees, and commits) in a git repository, the files which store these /aren't/ updated; "modified" contents will, by virtue of being different, receive a different ID and therefore end up in a different file. The whole thing is actually quite similar to the way Tcl handles values and variables. Commits, trees, and blobs are immutable like a value (indeed, this is very much because EIAS), while "branch heads" and tags are mutable like a variable. You can change what value is stored in a variable, but you cannot alter the value itself. Lars Hellström |
From: Will D. <wi...@wj...> - 2011-02-15 00:36:37
|
Andreas, I don't have any particular preference. I use fossil, and like it; git is clearly worth learning, and I've been meaning to do that. And either will work. I think the question is, do we want to host it "ourselves", in which case Fossil is the big winner, or do we want to let someone else host it, in which case git is the big winner. It probably makes sense to adopt whatever is adopted for the Tcl core. Will On Feb 14, 2011, at 1:21 PM, Andreas Kupries wrote: > Hi all you developers of Tcllib, Tklib, BWidget, etc. .. > > You might have noted that the SourceForge CVS was down for two weeks, > after a hack attack on them. > > This downtime ended last week, allowing us, in principle, to continue > development and re-start commits. > > There is however a fly in the soup. Quoting from Jeff's mail to tcl-core > > In the interim, SF also let us know that cvs is now considered > a legacy service. > > In other words, the end-of-life of CVS repositories on SF, and maybe in general > is on the radar now, and it behooves us, IMHO, to do the transition to > something else _now_. > > As such I ask everyone to hold back from commiting anything to any of the > projects under tcllib (1) until we have this issue resolved. > > > While SourceForge apparently will offer a migration service from CVS to SVN I > agree with Jeff that we should transition to a proper DVCS instead. > > Related to the choicce of DVCS is also the issue of hosting, i.e. depending on > what our choice of system we have less or more options for hosting. > > Following the discussions on the chat, about the same issue, only for core > Tcl/Tk the main contenders are > > our own Richard Hipp's "fossil" (2), > and the ubiquitous 800lb gorilla "git" (3) > > From a technical point of view both will do the job, and are pretty much > equivalent. Conversion to either should be relatively trivial via "cvs2git" > (4), both support the fast-export file-format generated by the converter. > > Non-technical arguments for either are > > * fossil is small, clean, simple, easy to learn, with the developer part > of the Tcl community, and known to be responsive. Pretty much on call. > > * git, while not small, and with a steep learning curve, however is > *ubiquitous*, with a much larger community. Students learn it. > Using it means that a GSoC student (for example), can simply be > pointed to the git repository and told to branch. > > * On the hosting front, using git give us lots of alternatives as: > > SourceForge, github, gitorious(sp?), assembla > > * For fossil we either have to either use the pretty much unknown > > chiselapp > > or self-host. The latter might actually not be to onerous, given that > fossil comes with a builtin web server. Just needs a box. > > * Richard has its own comparison and reasons for either at > http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki > > > Do I have my own preference ? Yes. And I sincerely hope that I managed to keep > it out of the arguments above. > > > One last issue. As (1) shows, we have lots of subprojects. Seven. While these > are all handled by a single CVS repository directory hierarchy, when going to > DVCS we should really split them up, each as their own XXX repository. One of > them, tclbench, should possibly even migrate out of the tcllib more to the core > itself, given that it is the core whose performance this project is testing. > > Discussion is open. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > (1) Which are > bwidget > mclistbox > tclapps > tclbench > tcllib (sic) > tklib > widget > > (2) http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki > (3) http://www.kernel.org/pub/software/scm/git/docs/git.html > > (4) In contrast to Tcl/Tk core tcllib does not have vendor branches in the > history AFAIK. > > -- > Andreas Kupries > Senior Tcl Developer > ActiveState, The Dynamic Language Experts > > P: 778.786.1122 > F: 778.786.1133 > and...@ac... > http://www.activestate.com > Get insights on Open Source and Dynamic Languages at www.activestate.com/blog > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Tcllib-devel mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcllib-devel Will Duquette, OP will -at- wjduquette dot com http://foothills.wjduquette.com/blog |
From: Andreas K. <and...@ac...> - 2011-02-15 01:11:11
|
On 2/14/2011 4:36 PM, Will Duquette wrote: > It probably makes sense to adopt whatever is adopted for the Tcl core. Gerald Lester made the same point in direct mail. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Steve L. <st...@di...> - 2011-02-15 07:58:23
|
On 15/02/2011, at 3:41 PM, Harald Oehlmann wrote: > Am 15.02.2011 02:10, schrieb Andreas Kupries: >> On 2/14/2011 4:36 PM, Will Duquette wrote: >>> It probably makes sense to adopt whatever is adopted for the Tcl core. >> >> Gerald Lester made the same point in direct mail. >> > Same opinion, tcllib is tcl - keep it close. Same opinion, with one caveat. Make sure the Tcl core developers keep the needs of Tcllib developers in mind too. Or (put differently) the decision isn't only about maintaining C code in the core. Steve |
From: Arjen M. <arj...@de...> - 2011-02-15 08:30:22
|
Hi everybody, On 2011-02-15 08:58, Steve Landers wrote: > On 15/02/2011, at 3:41 PM, Harald Oehlmann wrote: > >> Am 15.02.2011 02:10, schrieb Andreas Kupries: >>> On 2/14/2011 4:36 PM, Will Duquette wrote: >>>> It probably makes sense to adopt whatever is adopted for the Tcl core. >>> Gerald Lester made the same point in direct mail. >>> >> Same opinion, tcllib is tcl - keep it close. > > Same opinion, with one caveat. Make sure the Tcl core developers keep the needs of Tcllib developers in mind too. Or (put differently) the decision isn't only about maintaining C code in the core. > I have no strong opinions one way or the other, except that I have experience with fossil, not with git. It seems quite sensible to adopt the same solution as for Tcl, but Steve's remark does raise a question: how would the needs for maintaining C and for maintaining Tcl differ? And how would that influence the decision for either? Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Harald O. <har...@el...> - 2011-03-03 07:17:31
|
I checked in a patch for bwidget/combobox.tcl yesterday. There was a warning from sourceforge which said "if this persists please contact sourceforge". The checkin is in the repository but I received no change information mail. -Harald |
From: Andreas K. <and...@ac...> - 2011-03-07 17:12:52
|
On 3/2/2011 11:12 PM, Harald Oehlmann wrote: > I checked in a patch for bwidget/combobox.tcl yesterday. > There was a warning from sourceforge which said "if this persists please > contact sourceforge". > The checkin is in the repository but I received no change information mail. > -Harald I believe the CIAbot, i.e. the script doing the notification mail got disabled after the attack on SF and subsequent cleanup. ... Going back into their blog (https://sourceforge.net/blog/) the relevant block of text, as of Feb 10 is =============================================================== CVS is back online (rsync, pserver, SSH and ViewVC), with a few caveats: xx - adminrepo via the Interactive Shell is temporarily offline ** - due to a reduced number of installed libraries, some hook scripts may not function properly ** - outbound email is not functional, so any script utilizing this will fail. If you need to send outbound email, a workaround would be to use curl and and external site or Project Web to send the email. =============================================================== The last two points (**) are the most relevant. This is something I am (likely) not able to fix. This is the last information they gave on this topic, i.e. I would believe that this situation regarding commit notifications is persisting. Point (xx) I have just confirmed by logging into their shell. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Harald O. <har...@el...> - 2011-03-08 07:15:08
|
Am 07.03.2011 18:11, schrieb Andreas Kupries: > On 3/2/2011 11:12 PM, Harald Oehlmann wrote: >> The checkin is in the repository but I received no change information mail. > The last two points (**) are the most relevant. > This is something I am (likely) not able to fix. Thank you, Andreas, IMHO you should not spent any time trying to fix this. Echeckin notification E-Mails are gone - ok, no problem. Thanks, Harald |
From: Michael S. <sc...@un...> - 2011-02-15 00:56:56
|
Hi Andreas, I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use. From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves us forward faster, who cares? And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share. So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate. I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best of breed for sure, so both fossils trackers and github or others might offer improvements. Michael |
From: Andreas K. <and...@ac...> - 2011-02-15 18:05:09
|
On 2/14/2011 4:41 PM, Michael Schlenker wrote: > Hi Andreas, > > I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use. > > From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of > users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves > us forward faster, who cares? > And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share. > > So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using I should clarify here my previous example/argument I made, about the GSoC student. The argument is one of "lower barrier to entry". It is not a (auto)magic visibility of the form "If you build it they will come". Even with going "git" Tcl(lib)s visibility is determined by actual marketing, i.e. evangelization. There is one argument which I was told in private mail, against "git", namely that it(s support) is not very good on windows, and that this might drive developers away, given that Tcl prides itself on good x-platform portability, which means that we need good windows support in our tools for easy development on that platform. At least for those people not using a mix of platforms like me (*). Regarding the core assumption behind the argument, of git not being good on Win, that I can't really evaluate. I haven't used git very much and not at all on Windows. Given my own preference for fossil I will certainly ask this question on the fossil list as well, for while I am using fossil often now I haven't used it on windows either. > a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate. I would not describe fossil as 'fringe' with its negative connotations. Niche, yes, fringe, no. > I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best > of breed for sure, so both fossils trackers and github or others might offer improvements. (*) With the mix of boxes I have access to, and the shared file systems all the VCS ops happen on linux and files are copied to windows boxes for building. No direct VCS ops on the windows boxes. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Damon C. <da...@tc...> - 2011-02-15 18:48:16
|
> Even with going "git" Tcl(lib)s visibility is determined by actual marketing, > i.e. evangelization. Yes, but you can't argue that Tcl will get more visibility on some fossil site than on some place like Github. Github has tremendous momentum behind it and has some really nice tools available. Though I would caution against their issue tracker since it is VERY barebones and kinda sucks. Also we run into the same issue of being able to get our data back out. Once we move to a DVCS we never need worry about getting our data back from someone else ever again. Everyone with a copy has all the history and data. Placing Tcl on Github can only help with visibility. > There is one argument which I was told in private mail, against "git", namely > that it(s support) is not very good on windows, and that this might drive > developers away, given that Tcl prides itself on good x-platform portability, > which means that we need good windows support in our tools for easy development > on that platform. At least for those people not using a mix of platforms like > me (*). > > Regarding the core assumption behind the argument, of git not being good on > Win, that I can't really evaluate. I haven't used git very much and not at all > on Windows. > > Given my own preference for fossil I will certainly ask this question on the > fossil list as well, for while I am using fossil often now I haven't used it on > windows either. Git on Windows is fine. It uses MSYS, which is not ideal, but with msysgit and TortoiseGit, you can be up and running doing Windows development in minutes. I use Git (and Github) for most of my projects now, and setting things up Windows has never been anything more than running a couple of installers. I'm familiar enough with Fossil as well, and I think either one would be a fine choice on their technical merits. So much so that I don't even feel it's worth arguing. You want to argue the difference between the engine in a Honda vs. a Toyota, but both are damn good engines and will get you where you need to go without a care. It's the trim and options we need to be looking at. Git has a TON of momentum behind it, both open source and commercial. I've been really surprised at the number of tools I've seen being created around Git. Given that I've only played with Fossil a little, I can't speak to the "options" it offers, but I've seen a few. A wiki? We already have a great wiki that is used by everyone in the community. A bug tracker? Well, that's definitely nice to have as we have seen that as a problem in the past. But a bug tracker can be written by any Tcl'er in a few nights if we had a mind to. There are other commercial and open source solutions out there, but do we want to get stuck in holding our data in another proprietary silo? That would be the one major advantage to Fossil is that the bugs are kept along with the source. What else? D |
From: Kevin K. <kk...@ny...> - 2011-02-16 02:27:13
|
On 02/15/2011 01:04 PM, Andreas Kupries wrote: > Regarding the core assumption behind the argument, of git not being good on > Win, that I can't really evaluate. I haven't used git very much and not at all > on Windows. Git sort of works on Windows, but you have to install a ton of other stuff first, and I'd practically have to virtualize to do it (cygwin conflicts and the like). Fossil is a single executable on Windows and works just as well there as it does on Unix. My only annoyance is that it cannot be configured to do line-ending substitution. One of these days I'll do some scripts to work around it; I understand drh's reluctance to have the capability in the fossil mainline, given that the committed version of a file must be bit-for-bit identical to what the developer presented. -- 73 de ke9tv/2, Kevin |
From: Jeff H. <je...@Ac...> - 2011-02-16 04:36:13
|
On 2011-02-15, at 6:27 PM, Kevin Kenny wrote: > On 02/15/2011 01:04 PM, Andreas Kupries wrote: >> Regarding the core assumption behind the argument, of git not being good on >> Win, that I can't really evaluate. I haven't used git very much and not at all >> on Windows. > > Git sort of works on Windows, but you have to install a ton of other > stuff first, and I'd practically have to virtualize to do it (cygwin > conflicts and the like). Fossil is a single executable on Windows and > works just as well there as it does on Unix. My only annoyance is that > it cannot be configured to do line-ending substitution. One of these > days I'll do some scripts to work around it; I understand drh's > reluctance to have the capability in the fossil mainline, given > that the committed version of a file must be bit-for-bit identical > to what the developer presented. That is false logic, and is why all other revision control systems have the option to tag a file as text or binary. To the developer, it's not bit-for-bit a file, it is a TEXT file with set contents. You should be able to diff, push and pull those across different OSes and see exactness (or lack thereof) in a TEXT context. Jeff |
From: Lars H. <Lar...@re...> - 2011-02-16 14:03:00
|
Kevin Kenny skrev 2011-02-16 03.27: > On 02/15/2011 01:04 PM, Andreas Kupries wrote: >> Regarding the core assumption behind the argument, of git not being good on >> Win, that I can't really evaluate. I haven't used git very much and not at all >> on Windows. > > Git sort of works on Windows, but you have to install a ton of other > stuff first, and I'd practically have to virtualize to do it (cygwin > conflicts and the like). Fossil is a single executable on Windows and > works just as well there as it does on Unix. My only annoyance is that > it cannot be configured to do line-ending substitution. That could actually be a show-stopper. It seems that quite commonly editors on Windows (at least those which students can easily obtain, install, and use) can only do CRLF line-ends, whereas Unix utilities (of course) insist on LF. Not getting line conversions out-of-the-box is to be asking for trouble. Lars Hellström |
From: Andreas K. <and...@ac...> - 2011-02-21 23:04:39
|
This seems to have puttered out. My decisions on this, for the moment: * Follow what Tcl/Tk core is doing * The CVS is generally open for commits again. When the actual transition comes up I will close it again. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Arjen M. <arj...@de...> - 2011-04-26 07:20:47
|
Hi Andreas, have we reached a conclusion for this issue yet? (My most pressing need at the moment is the development of a new version of Plotchart, which I am developing together with Torsten Berg) Regards, Arjen On 2011-02-15 19:04, Andreas Kupries wrote: > On 2/14/2011 4:41 PM, Michael Schlenker wrote: >> Hi Andreas, >> >> I personally do not really care if either Git or Fossil gets picked, both are fine for the intended use. >> >> From a more global perspective it might be better to pick Git instead of Fossil due to the larger group of >> users already knowing Git in general, compared to fossil. It is the 800 lbs gorilla, but if that one moves >> us forward faster, who cares? > >> And it is not really in doubt that there are and will be more tools available for Git than for fossil due to the pure market share. >> >> So, for political reason I would cast a vote for Git. Its good enough for the job, gives Tcl(lib) some more visibility than using > > I should clarify here my previous example/argument I made, about the GSoC > student. The argument is one of "lower barrier to entry". It is not a > (auto)magic visibility of the form "If you build it they will come". > > Even with going "git" Tcl(lib)s visibility is determined by actual marketing, > i.e. evangelization. > > There is one argument which I was told in private mail, against "git", namely > that it(s support) is not very good on windows, and that this might drive > developers away, given that Tcl prides itself on good x-platform portability, > which means that we need good windows support in our tools for easy development > on that platform. At least for those people not using a mix of platforms like > me (*). > > Regarding the core assumption behind the argument, of git not being good on > Win, that I can't really evaluate. I haven't used git very much and not at all > on Windows. > > Given my own preference for fossil I will certainly ask this question on the > fossil list as well, for while I am using fossil often now I haven't used it on > windows either. > > >> a (nice, but) 'fringe' system like fossil, and makes it easier for others to participate. > > I would not describe fossil as 'fringe' with its negative connotations. Niche, > yes, fringe, no. > >> I think we should also look at other things like issue/bug trackers when doing the move, the Sourceforge trackers are far from best >> of breed for sure, so both fossils trackers and github or others might offer improvements. > > (*) With the mix of boxes I have access to, and the shared file systems all the > VCS ops happen on linux and files are copied to windows boxes for building. No > direct VCS ops on the windows boxes. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Gerald W. L. <Ger...@co...> - 2011-04-26 13:03:44
|
On 4/26/11 2:20 AM, Arjen Markus wrote: > Hi Andreas, > > have we reached a conclusion for this issue yet? (My most pressing > need at the moment is the development of a new version of Plotchart, > which I am developing together with Torsten Berg) Arjen, According to my email log TclLib was going to follow Core and use fossil. I'm not sure why the leap has not been made yet. Andreas, if this is correct -- do we have a schedule for making the jump? Also, are we going to use the fossil bug tracking or stay with the SF bug tracking? -- +------------------------------------------------------------------------+ | Gerald W. Lester | |"The man who fights for his ideals is the man who is alive." - Cervantes| +------------------------------------------------------------------------+ |
From: Arjen M. <arj...@de...> - 2011-04-26 13:06:07
|
Hi Gerald, that is what I understood at the time, but then the decision about the core was not yet made. Now that it is, it seems we should make the jump too. Regards, Arjen On 2011-04-26 15:03, Gerald W. Lester wrote: > On 4/26/11 2:20 AM, Arjen Markus wrote: >> Hi Andreas, >> >> have we reached a conclusion for this issue yet? (My most pressing >> need at the moment is the development of a new version of Plotchart, >> which I am developing together with Torsten Berg) > Arjen, > > According to my email log TclLib was going to follow Core and use fossil. > I'm not sure why the leap has not been made yet. > > Andreas, if this is correct -- do we have a schedule for making the jump? > > Also, are we going to use the fossil bug tracking or stay with the SF bug > tracking? > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Kevin K. <kk...@ny...> - 2011-04-26 13:35:18
|
On 04/26/2011 09:03 AM, Gerald W. Lester wrote: > On 4/26/11 2:20 AM, Arjen Markus wrote: >> Hi Andreas, >> >> have we reached a conclusion for this issue yet? (My most pressing >> need at the moment is the development of a new version of Plotchart, >> which I am developing together with Torsten Berg) > Arjen, > > According to my email log TclLib was going to follow Core and use fossil. > I'm not sure why the leap has not been made yet. > > Andreas, if this is correct -- do we have a schedule for making the jump? > > Also, are we going to use the fossil bug tracking or stay with the SF bug > tracking? My $0.02: Please stay with SF bug tracking. Fossil's bug tracking isn't ready. I say this as probably the guy with the most experience transferring a bug DB from SF to Fossil. The transfer works, and I'm quite confident about the data integrity, now and moving forward, but the UI and workflow are both in need of some serious love and I don't have time to put in the necessary work. -- 73 de ke9tv/2, Kevin |
From: Andreas K. <and...@ac...> - 2011-04-26 14:34:43
|
On 4/26/2011 6:03 AM, Gerald W. Lester wrote: > On 4/26/11 2:20 AM, Arjen Markus wrote: >> Hi Andreas, >> >> have we reached a conclusion for this issue yet? (My most pressing >> need at the moment is the development of a new version of Plotchart, >> which I am developing together with Torsten Berg) > Arjen, > > According to my email log TclLib was going to follow Core and use fossil. > I'm not sure why the leap has not been made yet. Sinking under my radar over time. > > Andreas, if this is correct -- do we have a schedule for making the jump? My apologies. We do not have a schedule. Right now I also do not have time for this, due to donuts eating it up. > Also, are we going to use the fossil bug tracking or stay with the SF bug > tracking? I would stay with the SF tracking. We can transfer an SF bug database to fossil just fine by now, in terms of data translation. However integration of old references in the changelogs and such isn't fully there yet, and our most experienced person in that area (Kevin) counsels against, at least not before the default setup in fossil got an overhaul. Which he, unfortunately doesn't have time for. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |
From: Arjen M. <arj...@de...> - 2011-04-26 14:50:52
|
Hi Andreas, understood. For the moment it is not a big deal. Regards, Arjen On 2011-04-26 16:34, Andreas Kupries wrote: > On 4/26/2011 6:03 AM, Gerald W. Lester wrote: >> On 4/26/11 2:20 AM, Arjen Markus wrote: >>> Hi Andreas, >>> >>> have we reached a conclusion for this issue yet? (My most pressing >>> need at the moment is the development of a new version of Plotchart, >>> which I am developing together with Torsten Berg) >> Arjen, >> >> According to my email log TclLib was going to follow Core and use fossil. >> I'm not sure why the leap has not been made yet. > > Sinking under my radar over time. > >> Andreas, if this is correct -- do we have a schedule for making the jump? > > My apologies. We do not have a schedule. > Right now I also do not have time for this, due to donuts eating it up. > >> Also, are we going to use the fossil bug tracking or stay with the SF bug >> tracking? > > I would stay with the SF tracking. We can transfer an SF bug database to fossil > just fine by now, in terms of data translation. However integration of old > references in the changelogs and such isn't fully there yet, and our most > experienced person in that area (Kevin) counsels against, at least not before > the default setup in fossil got an overhaul. Which he, unfortunately doesn't > have time for. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Andreas K. <and...@ac...> - 2011-04-26 14:52:09
|
On 4/26/2011 7:50 AM, Arjen Markus wrote: > Hi Andreas, > > understood. For the moment it is not a big deal. Note that the CVS at SF currently works, and is open to commits. I.e. plotchart work can go into tklib. > > Regards, > > Arjen > > On 2011-04-26 16:34, Andreas Kupries wrote: >> On 4/26/2011 6:03 AM, Gerald W. Lester wrote: >>> On 4/26/11 2:20 AM, Arjen Markus wrote: >>>> Hi Andreas, >>>> >>>> have we reached a conclusion for this issue yet? (My most pressing >>>> need at the moment is the development of a new version of Plotchart, >>>> which I am developing together with Torsten Berg) >>> Arjen, >>> >>> According to my email log TclLib was going to follow Core and use fossil. >>> I'm not sure why the leap has not been made yet. >> >> Sinking under my radar over time. >> >>> Andreas, if this is correct -- do we have a schedule for making the jump? >> >> My apologies. We do not have a schedule. >> Right now I also do not have time for this, due to donuts eating it up. >> >>> Also, are we going to use the fossil bug tracking or stay with the SF bug >>> tracking? >> >> I would stay with the SF tracking. We can transfer an SF bug database to >> fossil just fine by now, in terms of data translation. However integration of >> old references in the changelogs and such isn't fully there yet, and our most >> experienced person in that area (Kevin) counsels against, at least not before >> the default setup in fossil got an overhaul. Which he, unfortunately doesn't >> have time for. >> > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may > contain confidential and privileged information. If you are not the intended > recipient please notify the sender immediately and destroy this message. > Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The > Netherlands, Commercial Registration Number 41146461, is not liable in any way > whatsoever for consequences and/or damages resulting from the improper, > incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog |