It looks like we've given enough time for finalizing development work, so I'd like to shift us into release mode by entering our Chill phase.
Here's the tasks to focus on now:
Chill. Development focuses on wrapping up. Identify 'make distcheck' issues Triage bug reports Run an About Screen contest First draft of Release Notes. Update tutorials and other docs
Triaging is probably the biggest task ahead of us. I'll try to focus my time on assisting here; I'll try to focus on scripting of bulk changes, as I've got several ideas for cleanup projects on the wiki.
Ted, could you post a listing of recent development work, and collect status from the developers, so we can see if there's any remaining absolutely must-do tasks before we release?
ACSpike, would you mind doing a first pass at running make distcheck and post to the list what errors there are that we'll need to sort out?
Ryan Lerch, can you give us an update on where things stand for bug triaging, and where other people can get involved?
Scislac, would you be able to run an about screen contest for us again? I figure we can do it just like the 0.45 contest.
Bulia, the Release Notes look like they're in great shape, but you generally have the best eye of any of us on them. Could you identify any major holes we need filled (esp. with names of people we need to get to write stuff up).
ScislaC and Bulia - how do we sit currently respecting tutorials and docs? I think it's too late in the game to start writing any new ones, but if there's high priority stuff that absolutely must get done, we should list it out now and make sure we've got people to tackle them.
Finally, if anyone has questions or concerns of anything that needs to be handled or accounted for during this release, or wishes to help out directly in the release process, this is the time to speak up. Let me know of any release issues and I'll help make sure they get straightened out.
Bryce
On Sat, Nov 03, 2007 at 10:56:46AM -0700, Bryce Harrington wrote:
Hi all,
Now that GSoC projects are finished and the code has had time to stabilize, it seems a good time to get the 0.46 release moving ahead. With Gutsy released, I finally have some time to contribute towards Inkscape release work, and will help try to get efforts organized.
I'd like to propose the following release plan, based roughly on the 0.45 plan. Let me know if there's anything missing.
Open development.
Chill. Development focuses on wrapping up. Identify 'make distcheck' issues Triage bug reports Run an About Screen contest First draft of Release Notes. Update tutorials and other docs
Frost. Most development complete. Release Notes should be >90% filled in. Bug Hunt: 500 points Post inkscape-0.46-alpha.tar.gz
Feature Freeze. No further development work. Disable features that can't be finished in time Focus on critical bug fixing. Finalize all tutorials, docs, etc. Finalize all extensions Translators create translations. Inkscape must pass 'make distcheck' Post inkscape-0.46-beta.tar.gz
Hard freeze. Only release wardens can commit to mainline. No further string changes Focus on release-critical bug fixing. Finalize translations, release notes, etc. Packagers test creating pkgs of the -beta release Post inkscape-0.46-rc1.tar.gz
Branch. Establish the Stable Branch for release Complete any late-late-late work. Final verification of packaging, release notes, docs, etc. Publish more release candidates until ready for release. Plan 0.46.1+ release(s), if needed
Release. Post inkscape-0.46.tar.gz Post packages Post official announcements
Open development.
I'm sort of thinking for this release we ought to plan on establishing a stable branch much earlier than we've done before, and maintain split devel / stable branches for a bit (maybe a couple months). I think that'd allow us to spend much more time than usual getting things release-worthy, without too heavily impacting people who wish to keep doing development work.
We'll have a bunch of interesting random tasks (mostly non-coding) to do to get the release polished up and ready to go. Are you interested in participating in the release team? Let me know!
Bryce
To preemptively answer anyone concerned about work they've still got under way and whether it's too late - don't panic, at this point we're not looking to put a stop to feature work, just to track it carefully so we can make sure it gets finished in time.
However, time is getting short, so please plan on getting it to a releaseable state within a week or two. If it'll take longer than that, or if you know it's going to add a number of bugs, please consider how we could disable or back it out.
Bryce
On Thu, Dec 06, 2007 at 04:38:04PM -0800, Bryce Harrington wrote:
Chill. Development focuses on wrapping up. Identify 'make distcheck' issues Triage bug reports Run an About Screen contest First draft of Release Notes. Update tutorials and other docs
Ted, could you post a listing of recent development work, and collect status from the developers, so we can see if there's any remaining absolutely must-do tasks before we release?
Bryce Harrington wrote:
To preemptively answer anyone concerned about work they've still got under way and whether it's too late - don't panic, at this point we're not looking to put a stop to feature work, just to track it carefully so we can make sure it gets finished in time.
Too bad I didn't see this before responding :) If you guys want to I think the patch could be included as is, and my refactoring / fixes could be added in a new branch.
By the way, is the patch tracker in Launchpad too? I haven't gone to check Launchpad out yet.
Gail
On Fri, Dec 07, 2007 at 09:49:47AM -0500, Gail Carmichael wrote:
Bryce Harrington wrote:
To preemptively answer anyone concerned about work they've still got under way and whether it's too late - don't panic, at this point we're not looking to put a stop to feature work, just to track it carefully so we can make sure it gets finished in time.
Too bad I didn't see this before responding :) If you guys want to I think the patch could be included as is, and my refactoring / fixes could be added in a new branch.
By the way, is the patch tracker in Launchpad too? I haven't gone to check Launchpad out yet.
Right, they're essentially one and the same now. There's a checkbox next to the upload file button for indicating patches, and we can search for bugs with patches attached.
So it's a bit different workflow than we're used to, but should be workable.
Longer term, probably following the 0.46 release, it sounds like there's strong support for moving to a distributed version control system (probably either git or bzr). These systems greatly reduce the need for something like a patch tracker, since cloning, branching, and merging are very easy.
For now though, just pop them into the bug tracker and make sure to flag them as patches.
Bryce
Bryce Harrington wrote:
For now though, just pop them into the bug tracker and make sure to flag them as patches.
I was partly also wondering whether the old patches migrated properly over. I'm also not sure if I have an account at Launchpad since I never received any of these crazy emails that were discussed earlier. I've been pretty much school-only focused for a while so I'm a bit behind yet have seen the gist of what's going on.
Gail
On Fri, Dec 07, 2007 at 03:36:06PM -0500, Gail Carmichael wrote:
Bryce Harrington wrote:
For now though, just pop them into the bug tracker and make sure to flag them as patches.
I was partly also wondering whether the old patches migrated properly over. I'm also not sure if I have an account at Launchpad since I never received any of these crazy emails that were discussed earlier. I've been pretty much school-only focused for a while so I'm a bit behind yet have seen the gist of what's going on.
Yep, they're all migrated over. There's one issue where if the patch was attached to the original post rather than a comment, it's a bit hard to find - look on the left for a box labeled 'Bug attachments'.
Bryce
On Fri, 7 Dec 2007 12:52:53 -0800, Bryce Harrington <bryce@...961...> wrote:
Yep, they're all migrated over. There's one issue where if the patch was attached to the original post rather than a comment, it's a bit hard to find - look on the left for a box labeled 'Bug attachments'.
Have we got a mapping from SF bug numbers to Launchpad bug IDs, btw? An awful lot of stuff makes reference to SF bug number, including commit messages and in-code comments.
-mental
On Fri, Dec 07, 2007 at 01:09:13PM -0800, MenTaLguY wrote:
On Fri, 7 Dec 2007 12:52:53 -0800, Bryce Harrington <bryce@...961...> wrote:
Yep, they're all migrated over. There's one issue where if the patch was attached to the original post rather than a comment, it's a bit hard to find - look on the left for a box labeled 'Bug attachments'.
Have we got a mapping from SF bug numbers to Launchpad bug IDs, btw? An awful lot of stuff makes reference to SF bug number, including commit messages and in-code comments.
Yep, if you know the SF bug number (e.g. 847365), you can get to it in LP via:
https://bugs.launchpad.net/inkscape/+bug/sf847365 --> https://bugs.launchpad.net/inkscape/+bug/170020
Also, if you know the LP number, the original SF number is listed at the top
Bug #170020 (sf847365), first reported on ...
Bryce
On Fri, 2007-12-07 at 17:27 -0800, Bryce Harrington wrote:
Yep, if you know the SF bug number (e.g. 847365), you can get to it in LP via:
https://bugs.launchpad.net/inkscape/+bug/sf847365 --> https://bugs.launchpad.net/inkscape/+bug/170020
Awesome!
-mental
On Fri, 7 Dec 2007 11:58:31 -0800, Bryce Harrington <bryce@...961...> wrote:
Longer term, probably following the 0.46 release, it sounds like there's strong support for moving to a distributed version control system (probably either git or bzr). These systems greatly reduce the need for something like a patch tracker, since cloning, branching, and merging are very easy.
The main role of the patch tracker is really to provide assignable work items to make sure that patches really get reviewed/merged by someone; so long as we still have an "authoritative tree", I don't see that need going away with the introduction of a DSCM -- actual patches may simply get replaced by serialized changesets.
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making everyone happy. git interoperability is supposed to be a goal of Mercurial, but I've not found much documentation on it yet.
-mental
On Fri, Dec 07, 2007 at 01:04:07PM -0800, MenTaLguY wrote:
On Fri, 7 Dec 2007 11:58:31 -0800, Bryce Harrington <bryce@...961...> wrote:
Longer term, probably following the 0.46 release, it sounds like there's strong support for moving to a distributed version control system (probably either git or bzr). These systems greatly reduce the need for something like a patch tracker, since cloning, branching, and merging are very easy.
The main role of the patch tracker is really to provide assignable work items to make sure that patches really get reviewed/merged by someone; so long as we still have an "authoritative tree", I don't see that need going away with the introduction of a DSCM -- actual patches may simply get replaced by serialized changesets.
I think this aspect is suitably covered now, if you do an advanced search and tick "Show bugs with patches" and milestone "Inkscape 0.46":
https://bugs.launchpad.net/inkscape/+bugs?field.milestone%3Alist=946&fie...
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Have you had a chance to play with bazaar much? I'm curious why you would prefer git or mercurial over it since it sounds like it has a better balance of robustness and lack of user-hostility. I don't have strong feelings either way, but the people I've talked with that have used both git and bzr seem to strongly prefer bzr (mainly on the basis of the interface, but they seem to appreciate other little features of it).
Bryce
On Fri, 2007-12-07 at 17:46 -0800, Bryce Harrington wrote:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Have you had a chance to play with bazaar much?
No, I hadn't. Until recently, the general consensus on the web about bzr had been "don't bother". It was generally so ill-considered that I didn't even bother evaluating it when I did the giant SCM bake-off a while back.
However, reviewing the consensus on the web today, it seems that it has improved enough in recent months that people are now rating it just behind git and mercurial. So I will give it a spin.
-mental
On Sat, Dec 08, 2007 at 03:03:28PM -0500, MenTaLguY wrote:
On Fri, 2007-12-07 at 17:46 -0800, Bryce Harrington wrote:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Have you had a chance to play with bazaar much?
No, I hadn't. Until recently, the general consensus on the web about bzr had been "don't bother". It was generally so ill-considered that I didn't even bother evaluating it when I did the giant SCM bake-off a while back.
However, reviewing the consensus on the web today, it seems that it has improved enough in recent months that people are now rating it just behind git and mercurial. So I will give it a spin.
There is a git-vs-bzr page from the bzr developers here, which might be of interest at highlighting some of the major differences:
http://bazaar-vcs.org/BzrVsGit
The things that to me sound particularly interesting for Inkscape are:
* Cleaner UI model: * Commands set more familiar for Subversion and CVS users * Lower learning curve - only a dozen core commands, users only need about five
* Bug tracker integration (Bugzilla, Trac, Launchpad): * Commits can auto-flip bug states to closed, etc. (Basically, just put "Closes: LP# 12345" in commit message) * Linking branches to bugs and blueprints
* Rich public API: Architecture allows for plugins / custom tools * Many existing plugins: Eclipse integration, web interfaces, log formatting, GUI frontends, etc. - http://bazaar-vcs.org/BzrPlugins * Python API: http://bazaar-vcs.org/WritingPlugins
* Enables larger variety of workflows: Solo, partner, lock-step, centralized, decentralized/shared, decentralized/gatekeeper, and decentralized/auto-gatekeeper
* Run tests on commit: PQM is an auto-gatekeeper that requires commits to pass test suite before being accepted to mainline tree.
* Better asynchronous sharing of patches: The send command generates a "merge directive" which includes metadata with the patch, which can be merged/pulled, or even applied manually via GNU patch.
* Better windows support: Has GUI client, works on FAT32 as well as POSIX, and has well-supported Windows installers.
* Easier administration: * Does repository packing automatically * Upgrade tools for switching between file formats * Branch reconfiguration tools for different workflows
Ted is really fascinated by the PQM stuff. The idea here is that we'd be able to hook up our 'make check' (and/or make distcheck) tests to bzr, so that every time a commit is pushed, a machine would run make check against it, and only if make check passes would the commit be allowed to enter mainline.
Given the number of times a Windows developer has committed an Inkscape change that broke Linux, or vice versa (or OSX), this seems like an exceedingly practical feature. I don't know if git has something like this, but regardless I think it's a feature that'd save a lot of angst in our project.
I'm uncertain about the current state of git's windows client, but I gather bzr's is pretty good. Since the windows client is the major reason we've not considered moving from svn to git so far, this could be a big point. In fact, the reason I got thinking about bzr for Inkscape to begin with was the windows client.
The workflow flexibility (and changeability) in bzr actually maps very well to our Inkscape project workflow. git is designed specifically to the kernel development 'decentralized+gatekeeper' workflow. We in Inkscape follow the 'centralized' workflow where generally everyone checks everything in centrally, except around releases where we switch to more of a gatekeeper type system, except that we have no way of enforcing that.
There's a really nice article summarizing different workflows. It even uses some of our OpenClipart SVG icons for illustrations (if you squint maybe you can see Andy's name on the Computer icon):
http://bazaar-vcs.org/Workflows
If we switched to git, we'd have to change our workflow to follow (not necessarily a bad thing, but forces everyone to change a little.) With bzr, we could retain our current centralized workflow, plus be able to better map to a true gatekeeper system at release time; people would also be able to switch to the decentralized approach as they feel ready by using the "bzr commit --local" option.
The launchpad integration with the auto-flipping of bug states is also a spiffy feature. It's kind of cool to commit code and see the bug automatically close. But I have to admit it doesn't save me much time in practice, since I always write a response to the bug reporter anyway, so manually closing the bug isn't a big deal. It's still fun to have though.
Bryce
Hello,
On 2007-December-09 , at 10:09 , Bryce Harrington wrote:
On Sat, Dec 08, 2007 at 03:03:28PM -0500, MenTaLguY wrote:
On Fri, 2007-12-07 at 17:46 -0800, Bryce Harrington wrote:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Have you had a chance to play with bazaar much?
No, I hadn't. Until recently, the general consensus on the web about bzr had been "don't bother". It was generally so ill-considered that I didn't even bother evaluating it when I did the giant SCM bake-off a while back.
However, reviewing the consensus on the web today, it seems that it has improved enough in recent months that people are now rating it just behind git and mercurial. So I will give it a spin.
There is a git-vs-bzr page from the bzr developers here, which might be of interest at highlighting some of the major differences:
I'm glad to see this discussed. Personally I see three important points:
- speed: given the development model of Inkscape (which is not likely to change only because of a new SCM system), svn get mainly two things wrong IMHO: speed (committing is slow, diffing is a nightmare... and I only use it superficially so I cannot even imagine how it could be for core developers) and merges. It looks like both git and bzr get merges right. git is extremely fast but I don't know about bzr.
- handling of renames and binary files. I put these two together since they both relate to the same difference between bzr and git. In git, files don't even actually exist in the data model, only their content matters. This makes working with binary files a pain (they actually have to be ignored in the repository), at least last time I checked. Renames are somehow transparent since if a code block is moved from a file to another it will be tracked down there. However this relies entirely on smart-guesses from git while bzr seems to keep track of file operations _and_ uses some heuristics too. What I don't know is: . how bzr deals with binary files. there are maybe not many in Inkscape code base itslef but there a many more in inkscape-web or other part of the repository and I guess that all those would be migrated too. . whether the fact that bzr keeps track of file and directory names makes it necessary to rename them using a bzr-provided tool (i.e. some svn mv equivalent). I would hate this deeply.
- availability and popularity. availability is trivial, and git seems to be a problem in this respect. On OS X, if that matters, svn, hg, bzr and git are all easily available and at reasonably recent versions. popularity is important too since popular tools are likely to see more third party tools/plugins being developed for them. This would actually be an argument in favour of keeping svn: it may suck big time in itself but third party tools (TortoiseSVN, IDE integration, web interfaces, ...) make it particularly easy to use. Both git and bzr are not served as well, as far as I know. However, to give and example of what I know, git is supported experimentally by TextMate on OS X, bzr isn't even known. I guess it is probably not and isolated case. It also seems like many more project (and in particular many big projects) use git rather than bzr: http://bazaar-vcs.org/WhoUsesBzr http://git.or.cz/gitwiki/GitProjects I am not versed enough in this domain to know how both projects will evolve. The fact that bzr is somehow backed up by Ubuntu makes me feel like easy to use front ends and nice GUI tools might evolve soon but it would be nice to know from someone who actually has real information ;)
Eventually it would be nice to have impressions from users of both git and bzr. Cairo and X.org use git so there's probably someone here knowing this well (Carl Worth? Bryce?).
JiHO --- http://jo.irisson.free.fr/
On Dec 9, 2007 7:37 AM, jiho <jo.irisson@...400...> wrote:
- speed: given the development model of Inkscape (which is not likely
to change only because of a new SCM system), svn get mainly two things wrong IMHO: speed (committing is slow, diffing is a nightmare...
Really? For me svn diffs instantaneously, and it does not even require internet connection for that because it diffs with its own backup copies.
Committing does take about a second per file, but I guess it's about as fast as possible for any internet transaction over my connection. It's about as fast as loading a moderate-sized web page.
On 2007-December-10 , at 00:14 , bulia byak wrote:
On Dec 9, 2007 7:37 AM, jiho <jo.irisson@...400...> wrote:
- speed: given the development model of Inkscape (which is not likely
to change only because of a new SCM system), svn get mainly two things wrong IMHO: speed (committing is slow, diffing is a nightmare...
Really? For me svn diffs instantaneously, and it does not even require internet connection for that because it diffs with its own backup copies.
In the case of an svn diff between the working copy and the current changes yes, this is fast, but as soon as one gives an old (<HEAD) revision number to diff with (e.g. svn diff -r 1600 somefile) it requires network access and is slow (and I have a LAN internet connection so it's probably the server's fault). It is even worst when diffing a whole directory (which is usually very useful). It's even worst for logs: all require network access. These two "features" combined make tracking changes in previous revisions (for bug tracking or similar activities) long and far from enjoyable. Bug tracking in itself is not really enjoyable (IMHO) so it should be made as easy and quick as possible.
Committing does take about a second per file, but I guess it's about as fast as possible for any internet transaction over my connection. It's about as fast as loading a moderate-sized web page.
Committing to the central repository (i.e. pushing in the case of git or bzr) is probably the only operations in which subversion can match the others, since the limiting factor for all is network access. But the fact that distributed scm commits (i.e. local commits) are very fast is good for committing often. It allows to keep track of smaller changes, possibility breaking things but keep it invisible from the others. Then, only when you changes look good and are stable can they be actually "committed" (pushed) to the central repository. Basically you can use commit as a stronger and safer "save" command and this looks very useful.
Just my 2 cents.
JiHO --- http://jo.irisson.free.fr/
On Sun, 9 Dec 2007 12:37:38 +0100, jiho <jo.irisson@...400...> wrote:
- handling of renames and binary files. I put these two together since
they both relate to the same difference between bzr and git. In git, files don't even actually exist in the data model, only their content matters. This makes working with binary files a pain (they actually have to be ignored in the repository), at least last time I checked.
... er, what? git has better handling of binary files than many SCMs that I've used. The main thing is that it isn't quite as easy as some to write custom merge hooks if you want to do non-trivial merges of binary files (trivial merges work fine).
-mental
On Sun, 2007-12-09 at 01:09 -0800, Bryce Harrington wrote:
Ted is really fascinated by the PQM stuff. The idea here is that we'd be able to hook up our 'make check' (and/or make distcheck) tests to bzr, so that every time a commit is pushed, a machine would run make check against it, and only if make check passes would the commit be allowed to enter mainline.
Bryce is right, I think that this is really cool. I imagine it could be built with some of the other DVCSes. Basically it sets up a mirror main branch so that you'd commit to that and then the only "person" who could commit to the "real" main is the PQM process.
I think some other interesting uses for it are to vet patches. For instance someone could submit a patch, but it wouldn't even be nominated for review if it didn't pass "make check". Also, to help translators realize more quickly when they forget closing tags in translated strings.
I was hoping that Launchpad would provide PQM service as part of their bazaar hosting, but it seems that it would require too much processor power at the moment. (If anyone knows someone in the supercomputer department at IBM...) So it would be something we'd have to set up as a project. High CPU, but no user facing code. I nominate Bryce's house ;)
--Ted
On Mon, 10 Dec 2007 04:15:21 +0000, Ted Gould <ted@...11...> wrote:
Bryce is right, I think that this is really cool. I imagine it could be built with some of the other DVCSes.
It's possible with pretty much any SCM that has commit (or push, as applicable) hooks, distributed or not. In a non-distributed SCM, you just designate a particular "PQM" branch in the repository.
-mental
On Mon, 2007-12-10 at 07:36 -0800, MenTaLguY wrote:
On Mon, 10 Dec 2007 04:15:21 +0000, Ted Gould <ted@...11...> wrote:
Bryce is right, I think that this is really cool. I imagine it could be built with some of the other DVCSes.
It's possible with pretty much any SCM that has commit (or push, as applicable) hooks, distributed or not. In a non-distributed SCM, you just designate a particular "PQM" branch in the repository.
I agree, but the nice part is that it's already done :)
--Ted
On Sun, 9 Dec 2007 01:09:49 -0800, Bryce Harrington <bryce@...961...> wrote:
I'm uncertain about the current state of git's windows client, but I gather bzr's is pretty good. Since the windows client is the major reason we've not considered moving from svn to git so far, this could be a big point. In fact, the reason I got thinking about bzr for Inkscape to begin with was the windows client.
bzr's windows client is fairly decent; the main issue I keep hearing about (and I don't know if it's fixed yet) is that it handles non-ASCII filenames on Windows very badly. Could you ask about that?
-mental
On Dec 9, 2007 1:09 AM, Bryce Harrington <bryce@...961...> wrote: ...
If we switched to git, we'd have to change our workflow to follow (not necessarily a bad thing, but forces everyone to change a little.) With bzr, we could retain our current centralized workflow, plus be able to better map to a true gatekeeper system at release time; people would also be able to switch to the decentralized approach as they feel ready by using the "bzr commit --local" option.
... I've set up git shared repositories, but I always tell the users to be very careful about committing to the repository at the same time since I heard that git does not do file locking on shared repositories. Does anyone with git experience know if this issue has been solved, or if this was ever an issue?
Personally, I'd just stick with CVS and tinderbox. :)
, John
On Mon, 10 Dec 2007 10:40:43 -0800, "John Faith" <jfaith7@...400...> wrote:
I've set up git shared repositories, but I always tell the users to be very careful about committing to the repository at the same time since I heard that git does not do file locking on shared repositories. Does anyone with git experience know if this issue has been solved, or if this was ever an issue?
Git's repository design means that it doesn't _need_ to do file locking.
A remote push will either succeed or fail atomically, without any risk of damage.
-mental
On Dec 7, 2007 5:04 PM, MenTaLguY <mental@...3...> wrote:
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making everyone happy.
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
bulia byak wrote:
On Dec 7, 2007 5:04 PM, MenTaLguY <mental@...3...> wrote:
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making everyone happy.
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
I don't think you'll spend much time learning. And likewise I don't think there is much in the way of user unapprochability in git anymore. There is no need for people who have no desire to use or are confused by the wealth of functionality in git to learn those parts. Everyday operations can be summarized in a few paragraphs or perhaps just a table mapping between svn and git. People who want those parts, however, are lost unless the base system supports them.
Bulia, what operations do you commonly use in svn?
Mental, what parts of git do you feel are particularly user unfriendly that are less so in mercurial?
Aaron
On Dec 8, 2007, at 10:47 AM, Aaron Spike wrote:
I don't think you'll spend much time learning. And likewise I don't think there is much in the way of user unapprochability in git anymore. There is no need for people who have no desire to use or are confused by the wealth of functionality in git to learn those parts. Everyday operations can be summarized in a few paragraphs or perhaps just a table mapping between svn and git. People who want those parts, however, are lost unless the base system supports them.
Bulia, what operations do you commonly use in svn?
Mental, what parts of git do you feel are particularly user unfriendly that are less so in mercurial?
The problem is that last time I checked there was still a lack of free UI tools for git on par with others.
There are also some issues with windows support.
Now, I think that for people who use command-line tools git is probably nicer, but that leaves out the group who doesn't.
Jon A. Cruz wrote:
The problem is that last time I checked there was still a lack of free UI tools for git on par with others.
There is not yet fully functional explorer integration on Windows (cf TortoiseSVN). It would be cool if someone picked up git-cheetah (http://repo.or.cz/w/git-cheetah.git/).
gitgui and gitk deserve mention. I have very little experience with either tool but they seemed useful.
There are also some issues with windows support.
There indeed are some issues, but the mingw port has been progressing quickly. Each time I check it is more useable. I'm now using it lightly on windows for a few projects at work. (http://code.google.com/p/msysgit/)
Now, I think that for people who use command-line tools git is probably nicer, but that leaves out the group who doesn't.
I think you make valid points that deserves more investigation.
Aaron Spike
On Sat, 2007-12-08 at 12:47 -0600, Aaron Spike wrote:
Mental, what parts of git do you feel are particularly user unfriendly that are less so in mercurial?
I think git forces you to think a little bit more about the revision tree when you work (which might not actually be a bad thing, as far as it goes...), basic status information is hard to come by with a single command (I use cg-status from cogito instead), and a few things are still needlessly inconvenient (e.g. pushing to a remote branch doesn't update the locally cached copy).
The big thing, though, is Win32 support. Mercurial just works on Win32, and there is even a TortoiseHg for Windows shell integration. I think the best you can do with git right now is a version compiled with cygwin, although there is a mingw port being worked on as well.
Aside from the excellent design of the git repository format, git's advantages lie mainly in its superior handling of branches and in its usefulness for quickly analyzing large revision histories -- I was recently able to quietly resolve a copyright dispute by analyzing our git history in minute or two, which, even if the tools were available, would have taken inhumanly long if I'd had only subversion to work from.
Actually, that gets to one of my pet peeves about Mercurial, though -- it does actually come with a number of nice analysis tools which emulate many of the best features in git (e.g. "bisect", which does a great job of automating searches for the revision that introduced a bug, especially when the history is complex and non-linear). They just aren't enabled by default: as extensions, you need to enable each one individually in a Mercurial configuration file on a per-user basis. Which is stupid.
Now, one nice thing about Mercurial and git is that, even though they have different repository formats, git and mercurial share a basic change model, so if we went with Mercurial, two-way interoperation between git and mercurial could still be nicer than with subversion. The story is generally not quite as nice for most other revision systems (though most of the DSCMs are reasonably compatible).
-mental
MenTaLguY wrote:
On Sat, 2007-12-08 at 12:47 -0600, Aaron Spike wrote:
Mental, what parts of git do you feel are particularly user unfriendly that are less so in mercurial?
I think git forces you to think a little bit more about the revision tree when you work (which might not actually be a bad thing, as far as it goes...), basic status information is hard to come by with a single command (I use cg-status from cogito instead), and a few things are still needlessly inconvenient (e.g. pushing to a remote branch doesn't update the locally cached copy).
The big thing, though, is Win32 support. Mercurial just works on Win32, and there is even a TortoiseHg for Windows shell integration. I think the best you can do with git right now is a version compiled with cygwin, although there is a mingw port being worked on as well.
Aside from the excellent design of the git repository format, git's advantages lie mainly in its superior handling of branches and in its usefulness for quickly analyzing large revision histories -- I was recently able to quietly resolve a copyright dispute by analyzing our git history in minute or two, which, even if the tools were available, would have taken inhumanly long if I'd had only subversion to work from.
Actually, that gets to one of my pet peeves about Mercurial, though -- it does actually come with a number of nice analysis tools which emulate many of the best features in git (e.g. "bisect", which does a great job of automating searches for the revision that introduced a bug, especially when the history is complex and non-linear). They just aren't enabled by default: as extensions, you need to enable each one individually in a Mercurial configuration file on a per-user basis. Which is stupid.
Now, one nice thing about Mercurial and git is that, even though they have different repository formats, git and mercurial share a basic change model, so if we went with Mercurial, two-way interoperation between git and mercurial could still be nicer than with subversion. The story is generally not quite as nice for most other revision systems (though most of the DSCMs are reasonably compatible).
-mental
For us, the big reason for a distributed system is the ability to work off-line (ie on a plane, train, in a cafe, during a boring meeting, etc) and then post up a day or two later. Or to work on something in a more sandbox situation for a few days or weeks and then upload and have it merged in. Meanwhile it makes frequent committing easy which is a good thing. I have tried both hg and bzr and if both were very easy for me to learn, not much effort will be required for most of you. We're now using hg. Of the two, I had read that bzr was really slow in bigger uploads/merges but maybe the Ubuntu guys can speak to that better.
On Sat, Dec 08, 2007 at 08:25:51PM -0700, miles wrote:
For us, the big reason for a distributed system is the ability to work off-line (ie on a plane, train, in a cafe, during a boring meeting, etc) and then post up a day or two later.
Yep, this is a huge feature. It's also wonderful when you're working someplace with a flaky wireless network (like a linux conference); you can commit as often as you go, and wait on pushing.
Or to work on something in a more sandbox situation for a few days or weeks and then upload and have it merged in.
Right, I was alluding to this earlier. For people who use the patch tracker as a make-shift sandbox (either because they don't yet have access to version control, or because they're not comfortable committing to mainline directly), this capability is handy.
It means we can ensure everyone has straightforward access to version control, even if we've not yet granted them the keys to mainline.
Meanwhile it makes frequent committing easy which is a good thing. I have tried both hg and bzr and if both were very easy for me to learn, not much effort will be required for most of you. We're now using hg. Of the two, I had read that bzr was really slow in bigger uploads/merges but maybe the Ubuntu guys can speak to that better.
I've talked with some of the bazaar developers about this. Indeed, in the past there were some big performance issues, and git was the better choice. However, this has been receiving a lot of attention and apparently with bzr 0.92 things have seriously improved. I gather bzr is about equivalent to git for most operations that matter.
The bazaar developer emphasized that these days git vs. bzr comparisons need to consider more than just performance. It's beginning to get neck and neck, and (he feels) usability and interface efficiency throws things to bzr's favor pretty solidly. In talking with hard core bzr users, I gather it's the "tool fitting hand" effect, like we see with inkscape - when the tool flows with your hands vs. when you're fighting with it and have to mentally shift focus to operate it; in the latter case you don't care if it performs better, it's still frustrating.
Bryce
On Dec 8, 2007 2:47 PM, Aaron Spike <aaron@...749...> wrote:
Bulia, what operations do you commonly use in svn?
update, diff, commit, log
also setting a revision for diff and update, to search back in history
On Sat, Dec 08, 2007 at 07:49:57PM -0400, bulia byak wrote:
On Dec 8, 2007 2:47 PM, Aaron Spike <aaron@...749...> wrote:
Bulia, what operations do you commonly use in svn?
update, diff, commit, log
also setting a revision for diff and update, to search back in history
Pretty much all current revision control systems (including git, bzr, and I think hg) have these same commands, and even call them by the same name.
As a git and bzr user, I pretty much have only needed update, diff, commit, log, and push.
About push - One thing that's a little different with these distributed version control systems is that commit is split into two parts - "commit" and "push".
Commit is where you check in the code and give a commit message. It's a local operation though, so can be done even without network access. Very handy if you like to code on the bus, plane, or typical linux conference. ;-)
Push actually sends the changes out to another site (typically the mainline repository, but not necessarily).
The net result is that compared with svn, commits are *really* *really* fast, and don't break your train of thought. You commit more frequently, and thus can roll back and forth easier since the changesets are smaller.
To underscore the utility of this - at UDS, Ted and Kees had an Inkscape hacking session, where Kees majorly redid the Print Dialog. He got it to a point where it worked okay, but there were still some issues. The hotel wireless was busted so he couldn't commit it (he wasn't even sure it was ready for general consumption due to remaining issues). He pressed on and unfortunately got the code into a non-functioning state, and couldn't figure out how to get it back to where it was, since all the work was done outside revision control. So even today we remain Print Dialog-less because of this. With git or bzr (or hg), this would have not been an issue; he could have just committed locally as he went, and rolled back as soon as he found himself in a dead end situation.
Bryce
On Sun, 09 Dec 2007 08:05:48 -0000, Bryce Harrington <bryce@...961...> wrote:
To underscore the utility of this - at UDS, Ted and Kees had an Inkscape hacking session, where Kees majorly redid the Print Dialog. He got it to a point where it worked okay, but there were still some issues. The hotel wireless was busted so he couldn't commit it (he wasn't even sure it was ready for general consumption due to remaining issues). He pressed on and unfortunately got the code into a non-functioning state, and couldn't figure out how to get it back to where it was, since all the work was done outside revision control. So even today we remain Print Dialog-less because of this. With git or bzr (or hg), this would have not been an issue; he could have just committed locally as he went, and rolled back as soon as he found himself in a dead end situation.
Every programmer (or hopeful novelist) should be running the following on a 5 mintue contab:
find <list of directories to be protected> -not -name "*~" -not -name "#*" -type f -mmin -5 -exec cp --backup=t --parents "{}" <location of backup directory>
This ensures that I can always go back in 5 minute intervals so long as I remember to just Ctl-S the files I'm working on. It has saved my bacon many times. The "-not" options are for Emacs users who don't want to keep the working files in their backup directory. I also have another cronjob that cleans out these "quickie" backups once they're more than 14 days old, as well as a more normal nightly backup.
The above can be adapted to Macs too. Windows, not so much AFAIK.
Thomas
On Sun, 09 Dec 2007 12:15:59 -0000, "Thomas Worthington" <tww@...1737...> wrote:
Every programmer (or hopeful novelist) should be running the following on a 5 mintue contab:
find <list of directories to be protected> -not -name "*~" -not -name "#*" -type f -mmin -5 -exec cp --backup=t --parents "{}" <location of backup directory>
Personally, I prefer making frequent local commits with a DSCM, since I can ensure that the saved copies are made at meaningful boundaries, the copies represent a tree-wide state, and I can attach useful descriptions to them.
It's worth noting that all the Inkscape hacking I did at the most recent LGM (and on the train on the way back) was done with a DSCM (git); I didn't actually push anything to SVN until after I got home, so I can attest to how awesome that workflow can be.
-mental
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of bulia byak Sent: zaterdag 8 december 2007 19:25 To: MenTaLguY Cc: inkscape-devel@lists.sourceforge.net; Bryce Harrington Subject: Re: [Inkscape-devel] Inkscape 0.46 Chill
On Dec 7, 2007 5:04 PM, MenTaLguY <mental@...3...> wrote:
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making
everyone
happy.
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
I also would like to be able to keep using SVN. TortoiseSVN is such a great tool for me. For example, TortoiseCVS lacks all nice things TortoiseSVN has. The two are really incomparable.
Functionality that I like and use every minute: update and in that same dialog clearly see which files are touched (and the show log button in that same dialog to only see the logs of revisions since the last update action. *Per file* commit, revert, diff, log, etc. Annotate per file.
I have not looked at the git ui for windows, so I do not know if this functionality is available.
Cheers, Johan
J.B.C.Engelen@...1578... wrote:
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of bulia byak Sent: zaterdag 8 december 2007 19:25 To: MenTaLguY Cc: inkscape-devel@lists.sourceforge.net; Bryce Harrington Subject: Re: [Inkscape-devel] Inkscape 0.46 Chill
On Dec 7, 2007 5:04 PM, MenTaLguY <mental@...3...> wrote:
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making
everyone
happy.
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
I also would like to be able to keep using SVN. TortoiseSVN is such a great tool for me. For example, TortoiseCVS lacks all nice things TortoiseSVN has. The two are really incomparable.
Then maybe Mercurial via Tortoise is the best of both worlds: http://tortoisehg.sourceforge.net/ Screenshot: http://tortoisehg.sourceforge.net/screenshots/tortoisehg-snapshot-contextmen...
This is the project that will likely convert me to Mercurial for my 3 little OS projects. I would like to see how it handles merge and diff, but I think that I'm already sold. Anything is preferable to Git.
I already use Mercurial for work. Not for the main source repository, over which I have no control, but for my own "portable" clone of their repository and their old proprietary SCM. I keep an Hg clone on my USB key to shuttle between the private LAN and the Net.
Mercurial is awesome, IMHO. And this statement is from someone who has used and loved Subversion for >5 years. And it's getting a lot of momentum from projects like Mozilla and OpenJDK. I think that its being Python-based, the portability problems are left to the Python-porters themselves.
bob
On Sat, Dec 08, 2007 at 02:24:53PM -0400, bulia byak wrote:
On Dec 7, 2007 5:04 PM, MenTaLguY <mental@...3...> wrote:
In an ideal world, it would be nice if people had the option to use mercurial to commit to a git repository in a similar fashion to how some people (me, at least) use git to commit to an SVN repository today. I think that would do a pretty decent job of making everyone happy.
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
I'm hoping that subversion stays because then I can use bzr without changing anyone else's workflows. (Launchpad can track CVS and Subversion trees and exports as a bzr branch.)
I haven't used mercurial much, but feature-wise, it seems similar to bzr. I'm really not a fan of git, but I suspect it's mostly due to my not spending hours reading up on how to use it. ;) bzr had treated me well so far -- I use it for a few personal projects.
I wish git or bzr would handle "real" cherry-picking though. I have no idea if mercurial does it right.
On Sun, 9 Dec 2007 16:30:11 -0800, Kees Cook <kees@...62...> wrote:
I'm hoping that subversion stays because then I can use bzr without changing anyone else's workflows. (Launchpad can track CVS and Subversion trees and exports as a bzr branch.)
I do essentially the same with git.inkscape.org. It should still be possible to arrange something like that with e.g. tailor, even if you aren't able to use Launchpad's integration any more.
I wish git or bzr would handle "real" cherry-picking though. I have no idea if mercurial does it right.
Could you elaborate?
-mental
On Mon, Dec 10, 2007 at 07:39:44AM -0800, MenTaLguY wrote:
On Sun, 9 Dec 2007 16:30:11 -0800, Kees Cook <kees@...62...> wrote:
I'm hoping that subversion stays because then I can use bzr without changing anyone else's workflows. (Launchpad can track CVS and Subversion trees and exports as a bzr branch.)
I do essentially the same with git.inkscape.org. It should still be possible to arrange something like that with e.g. tailor, even if you aren't able to use Launchpad's integration any more.
Agreed. The real benefit with the bzr-from-CVS (which obviously doesn't apply to us) is that the LP tool actually builds logical commits out of CVS, which greatly simplifies dealing with big CVS commits. Anyway, doesn't matter for us.
I wish git or bzr would handle "real" cherry-picking though. I have no idea if mercurial does it right.
Could you elaborate?
Sure. One of the benefits of both git and bzr is the intelligent merging, since they're both very branch-aware. From what I've been able to see while doing git cherry-picking is that while it can hunt down the patch and build a merge for a given cherry-pick, there's really no lasting information that a given patch came from some branch or not.
For example, one of the usb video drivers in the Ubuntu Dapper kernel git tree had been updated for some features. The Ubuntu Edgy kernel did not have those changes. There was no way to query "what branches have been applied to this usb video code?" and I had to muck about trying to apply various upstream branches until I found the one that applied cleanly. As it stands (with both git and bzr AFAICT), there isn't really a way to do backporting cherry-picks. You _can_ do cherry-picks, but it's really nothing more than an elaborate "find a patch" process (which, don't get me wrong, is nice but it kind of feels incomplete).
Again, I'm bringing up topics that don't really apply to making a decision about a VCS. :P
Kees Cook confrontò:
For me, an even happier thing would be keeping the ability to use svn regardless of your switching to git or whatever. I never work on more than one piece of code at a time and svn is perfectly adequate for me. I really don't see a sufficient reason for me to spend time on learning yet another system.
I'm hoping that subversion stays because then I can use bzr without changing anyone else's workflows. (Launchpad can track CVS and Subversion trees and exports as a bzr branch.)
I haven't used mercurial much, but feature-wise, it seems similar to bzr. I'm really not a fan of git, but I suspect it's mostly due to my not spending hours reading up on how to use it. ;) bzr had treated me well so far -- I use it for a few personal projects.
Mercurial has the benefit of a simple command line syntax (similar to the Bazaar/SVN one) with speed and robustness similar to those of GIT.
I've used quite a bit CVS, SVN and Darcs but for my personal projects I've used Mercurial and found quite satisfying: I even track their mailing lists and I've written a simple extension (hg purge).
It currently lacks the great amount of plugins and scripts that Bazaar and GIT have, but the most useful ones are already there.
Ultimately there have been a big interest of some users in the integration with the Windows shell with the TortoiseHG project and the "Batteries Included" installer.
Unfortunately it is also the one that has the lesser integration with SVN, so I'd rather do a full conversion.
On the other hand I'd rather do a full conversion even with GIT and Bazaar, as syncing with SVN gives a lot of troubles due to its limitations (no arbitrary commit metadata, difficulties of tracking merge changesets).
Also note that Mercurial has a fast pure-HTTP protocol, so it works even behind a HTTP proxy (unlike the git: protocol) without being too slow (unlike the plain http: protocol in GIT).
I wish git or bzr would handle "real" cherry-picking though. I have no idea if mercurial does it right.
No, the Mercurial history model is the same of git/monotone and it doesn't allow true cherry picking (even if you get quite similar results with the transplant extension).
The only one that really does it is Darcs, but it has a truckload of other problems. :(
MenTaLguY dichiarò:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Just curious, why do you think that git is more robust than mercurial?
However I agree that mercurial is a lot simpler, at least like bzr (or svn), while git can be intimidating.
On Sun, 09 Dec 2007 20:52:58 +0100, Emanuele Aina <em@...1809...> wrote:
Incidentally, as far as DSCMs go, I'd personally recommend either git or mercurial. git is more robust (I would prefer to keep our core history in git format) and has better analysis tools (which I've come to rely on heavily), but mercurial is much less user-hostile.
Just curious, why do you think that git is more robust than mercurial?
Git stores everything as read-only files, named with the cryptographic hash of their contents. Files are never modified once created, and all operations are atomic at the filesystem level, mostly obviating the need for locking.
Mercurial stores each file's history separately, with multiple revisions combined in the same file, sort of like CVS. These files are append-only, but do require locking for updates.
In reality, I think Mercurial is only "non-robust" by comparison to git, since Mercurial is pretty careful about detecting when something has gone wrong. I just prefer systems where it isn't possible for something to go wrong in the first place (down to the guarantees given by the operating system, at least).
-mental
MenTaLguY spiegò:
Just curious, why do you think that git is more robust than mercurial?
Git stores everything as read-only files, named with the cryptographic hash of their contents.
As you mentioned it, storing files as read-only is one of the most annoying features of SVN and GIT. :)
It only makes people use "rm -Rf" blindly to delete a tree... :(
However, I'm not sure that what you said is also true when considering packs, as it is a form of repo rewrite, but my understanding of GIT's internals is limited.
Files are never modified once created, and all operations are atomic at the filesystem level, mostly obviating the need for locking.
Oh, you're right, Mercurial does need a bit of locking while doing a commit.
The main benefit of the Mercurial repo format is the total lack of maintenance, while in GIT you have to repack and prune once in a while or the performances will degrade over time.
Mercurial stores each file's history separately, with multiple revisions combined in the same file, sort of like CVS. These files are append-only, but do require locking for updates.
Also, with the transactions-based approach it is still quite robust, as if something fails before the end of the commit/push the files are simply truncated in a trivial manner and the repo consistency is restored.
In reality, I think Mercurial is only "non-robust" by comparison to git, since Mercurial is pretty careful about detecting when something has gone wrong. I just prefer systems where it isn't possible for something to go wrong in the first place (down to the guarantees given by the operating system, at least).
Fortunately as both are based on cryptographic hashes it is very easy to detect errors. :)
I always appreciated the simpler design of the initial GIT repo format, but with the addition of packs the elegance is gone.
As far as I'm concerned the Mercurial solution is the right tradeoff between elegance and performance.
On Dec 7, 2007 3:58 PM, Bryce Harrington <bryce@...961...> wrote:
Longer term, probably following the 0.46 release, it sounds like there's strong support for moving to a distributed version control system (probably either git or bzr). These systems greatly reduce the need for something like a patch tracker, since cloning, branching, and merging are very easy.
I thought our patch tracker is not for facilitating "cloning, branching, and merging", but just for tracking contributions from non-developers.
Bryce Harrington wrote:
ACSpike, would you mind doing a first pass at running make distcheck and post to the list what errors there are that we'll need to sort out?
Jiho, Could you please look into the first dist check issue?
make: *** No rule to make target `packaging/macosx/inkscape_python.ds_store', needed by `distdir'. Stop.
Aaron
Aaron Spike wrote:
Bryce Harrington wrote:
ACSpike, would you mind doing a first pass at running make distcheck and post to the list what errors there are that we'll need to sort out?
Jiho, Could you please look into the first dist check issue?
make: *** No rule to make target `packaging/macosx/inkscape_python.ds_store', needed by `distdir'. Stop.
Looks like two other files have been removed and remain in the Makefiles:
src/extensions/internal/gnome.cpp src/extensions/internal/gnome.h
Anyone know their story?
Also, what do we do (if anything) about messages like: tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/Scrollbars_1/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/Scrollbars_6/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/Scrollbars/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks-Quicksilver-OSX/gtk-2.0/sync_osx_look.sh: file name is too long (max 99); not dumped
Aaron
On Fri, 2007-12-07 at 07:30 -0600, Aaron Spike wrote:
Looks like two other files have been removed and remain in the Makefiles:
src/extensions/internal/gnome.cpp src/extensions/internal/gnome.h
Anyone know their story?
They were for GNOME Print support, but that's no longer supported upstream or really by us. Did I forget to remove them from somewhere? I thought I got everywhere...
--Ted
On 2007-December-07 , at 14:30 , Aaron Spike wrote:
Aaron Spike wrote:
Bryce Harrington wrote:
ACSpike, would you mind doing a first pass at running make distcheck and post to the list what errors there are that we'll need to sort out?
[..]
Also, what do we do (if anything) about messages like: tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks- Quicksilver-OSX/gtk-2.0/Scrollbars_1/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks- Quicksilver-OSX/gtk-2.0/Scrollbars_6/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks- Quicksilver-OSX/gtk-2.0/Scrollbars/: file name is too long (max 99); not dumped tar: inkscape-0.45+devel/packaging/macosx/Resources/themes/Clearlooks- Quicksilver-OSX/gtk-2.0/sync_osx_look.sh: file name is too long (max 99); not dumped
Well, I could shorten the names for example ;) But that's a strange limitation of tar...
JiHO --- http://jo.irisson.free.fr/
On 2007-December-07 , at 14:08 , Aaron Spike wrote:
Bryce Harrington wrote:
ACSpike, would you mind doing a first pass at running make distcheck and post to the list what errors there are that we'll need to sort out?
Jiho, Could you please look into the first dist check issue?
make: *** No rule to make target `packaging/macosx/ inkscape_python.ds_store', needed by `distdir'. Stop.
Ooops. sorry. I removed the file but not removed its mention in Makefile.am. This is corrected now. BTW, just to be sure: whenever I add a file, any file, to the repo, I should add it to some Makefile.am, even if it does not need to be compiled or anything, is that right? I don't know autoconf/automake at all so...
JiHO --- http://jo.irisson.free.fr/
Bryce Harrington wrote:
It looks like we've given enough time for finalizing development work, so I'd like to shift us into release mode by entering our Chill phase.
Hi Bryce, I'm hoping I will still be able to include my patch changes (refactoring etc, no changes in functionality) during chill. I have a couple of school projects to finish up but this is the first thing I want to do once they're done. So by the end of December, for sure, but likely sooner. Will keep you all updated.
Gail
participants (15)
-
unknown＠example.com -
Aaron Spike -
Bob Jamison -
Bryce Harrington -
bulia byak -
Emanuele Aina -
Gail Carmichael -
jiho -
John Faith -
Jon A. Cruz -
Kees Cook -
MenTaLguY -
miles -
Ted Gould -
Thomas Worthington