gmane.comp.version-control.arch.devel

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Lalo Martins — 2005-08-09T00:30:37

But the really funny thing is, what he said originally was: This could be interpreted as implying that Canonical's "unfriendly forks", either fix bugs more reliably, or accept patches more easily, or both ;-) tongue-in-cheek-ly yours, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo< at >exoweb.net GNU: never give up freedom http://www.gnu.org/

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthew Hannigan — 2005-08-08T23:56:20

Compare this to the refreshing attitude of svk's author: http://svk.elixus.org/?SVKSucks "Here are recollections of my ramblings and rants on how much SVK sucks, based on daily usage in production environments. This is here because ChiaLiangKao claims that he is motivated by complaints. Being mainly motivated by thank-you mails, I cannot comprehend that claim, but I dutifully complained anyway." -- Matt

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthew Hannigan — 2005-08-08T23:50:42

> [ ... ] So, use autoconf not pf.

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthieu Moy — 2005-08-08T06:39:52

You're considering the bazaar fork as an "unfriendly fork", although at that time, you've considered bazaar as the development branch for tla. You can talk about the quality of patches from bazaar, but NOT of the unfriendlyness of the fork. YOU are the one who refused to merge the bazaar stuff. YOU are the one who decided that bazaar would be a fork and not a branch. True. But I had to patch tla's Makefiles to be able to compile it on my Linux box first time I've tried too. I also came accross a very serious bug in str_n_cpy, that you took months to fix (as a reminder, this was a one line patch). So, it seems that you don't consider _your_ bugs as important (the history of bug tracking^W^W^W^Wforgetting with tla is representative of this statement IMHO), while you consider bugs from other people as "highly problematic". Reminder: Someone reported a bug and sent a patch for tla 2.0. No one was talking about bazaar or Canonical. You answered, I'll cite it again for those who missed it: ,---- | On Tue, 2005-08-02 at 23:24 -0500, Matthew Dempsky wrote: | > There's a typo in revc/api/revc_next_revname.c. See attached diff. | > | | Thanks. Perhaps I should just wait for Canonical to fix it | in their inevitable unfriendly fork. | | -t `---- But I'm probably the one who forced the matter. Please, once again, do not try to rewrite history. Let's talk about software engineering. Just look at this page: http://www.gnu.org/software/gnu-arch/ and look at what the link "bug database" points to (for those who missed it: a bugtracker that was abandonned for GNU Arch years ago). How can you talk about software engineering after the ton of bug report and merge request that you simply ignored. Let's talk about cooperation too. Where's your tla 2.0 archive? Because your were not happy with the way other people work (and your inability to delegate -- remember 1.2.2rc2 and 1.4rc1 ...), you've written tla 2.0 alone, making sure that no one could interfer with your process.

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Thomas Lord — 2005-08-07T23:36:15

I've no idea what history you think I'm rewriting. In the early history of baz I didn't come across a single major patch from that side of the wall that so much as conformed to years and years-old GNU formatting conventions let alone was of a suitable quality to just merge. Last time I tried, baz didn't even *compile* on the not-very-far-out-of-date BSD-based platform I was developing on at the time. A critical examination of their "mission statement" publications will show that they've expressed, at most, lip-service loyalty to the original project -- and that certainly jives with all of the IRC and off-list email conversations I've had. "Volunteerism" towards a project like mine doesn't count positively when the basic message from the volunteer is "keep up or die (we'll take over) and, by the way, to keep up, you'll have to conjure up many extra hours of labor if you want to maintain your standards because we ain't gonna try." That's the kind of "volunteerism" that bankrupts the receiver. It's painful to report such things (though you've forced the matter) because of the ambiguity. At the same time I have these gripes, I won't hesitate to remark that the canonical crew have poured hours and hours into helping newbies on IRC, hosting major and critical infrastructure like gnuarch.org (in all of its aspects), and have a slightly good-kinda-crazy founder who appears to be making a good faith (if not entirely agreeable) attempt at a socially responsible effort at commercializing free software. At the same time, people do share with me plenty of rumors of resentment among free software hackers at their approach and those rumors do resonate with me, invoking a kind of recognition of my own experience. And it's ambiguous too because, what the hell? Why should some company on the opposite side of the planet be all that responsible to an effort whose physical home is near the heart of Silicon Valley? Aren't there other players on the map here? Must it *all* come down to what they do? Aren't they entitled to pursue their own agenda? I'm torn. I am disgusted by interactions I've had with that crew, disappointed in their approach to software engineering, and feeling (fatally) disrespected by their approach to cooperation -- yet it would be bogus to blame them for all the world's evils, too. Perhaps that is my larger point. IMO, things have gone badly wrong in terms of cooperation in general on Arch. (I think a certain subset of current eager contributors to baz are being misled and abused about the nature of quality in software engineering). Who to blame? Probably nobody in particular. That doesn't make the issue either non-existent or unimportant. -t

Re: Showing ancestor in 3 way merge.

David Allouche — 2005-08-07T20:46:04

Showing ancestor in 3 way merge.

Matthieu Moy — 2005-08-07T18:47:03

Hi, In thelove< at >canonical.com/bazaar--devo--1.5--patch-20, I /tried/ to implement a --show-ancestor option for merge commands. The idea is that the conflict markers should be of the form <<<<<<< TREE lines from TREE ||||||| ANCESTOR lines from ANCESTOR ======= lines from MERGE-SOURCE This would be quite usefull in the case of a small patch applied in a large portion of modified file (TREE and ANCESTOR do not differ much, but ANCESTOR and MERGE-SOURCE have many difference). The way I've implemented it was to remove the "-E" option in the call to diff3. This works fine in the case where TREE and MERGE-SOURCE do not have the same modifications applied. Unfortunately, it also reports a conflict when TREE and MERGE-SOURCE are identical and different from ANCESTOR. Does anybody know the best way to implement what I'm looking for? I didn't find an option doing this in diff3. Either it reports too many conflicts or it doesn't show the ancestor in the conflict markers. Thanks for your help.

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthieu Moy — 2005-08-07T13:43:25

Shall I remind also that bazaar _has_ been considered as the development branch for tla at a time. http://lists.gnu.org/archive/html/gnu-arch-users/2005-01/msg00108.html From: Matthew Dempsky > Tom, could you share your thoughts about tla in relation to alternate > GNU Arch implementations such as baz? I'm in particular concerned about > compatibility between available GNU Arch implementations. Tom would likely respond that baz is a development branch of GNU arch. Compatibility shouldn't be a problem, especially as tla catches up with baz. A 1.4rc1 was released with many patches merged from bazaar. Then only, Tom decided that using bazaar as the development branch for tla was "highly problematic" ( http://lists.gnu.org/archive/html/gnu-arch-users/2005-02/msg00090.html ) After that, tla 1.3.1 was released, rejecting most interesting changes from the 1.4 release candidate (seletive undo, "tla switch", ...). For many people, including me, bazaar is the only way to contribute to "GNU Arch". In short: Tom, please, don't try to rewrite history.

important web site updates

Thomas Lord — 2005-08-05T19:04:33

I've made an important change (first link) to http://www.gnuarch.org and http://www.seyza.com Thanks, -t

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Christian Aichinger — 2005-08-03T15:35:16

Re: Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

John A Meinel — 2005-08-03T15:04:06

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Neal Becker — 2005-08-03T12:35:08

Don't know why, but make system is broken on revc.0.0x2. After doing mkdir build cd build ../configure make If I do again make or make install everything is re-compiled, tests are re-run, etc. This is bad, because I (like many others) want to do make sudo make install and step2 fails if build dir is nfs mounted.

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Eric Wong — 2005-08-03T06:06:53

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Thomas Lord — 2005-08-03T04:51:07

Thanks. Perhaps I should just wait for Canonical to fix it in their inevitable unfriendly fork. -t

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthew Dempsky — 2005-08-03T04:24:33

Re: [ANNOUNCE] Arch 2.0 release (revc.0.0x2)

Matthew Dempsky — 2005-08-03T00:11:14

Re: build-config, I need your opinion.

David Allouche — 2005-08-02T17:32:27

Re: build-config, I need your opinion.

Matthieu MOY — 2005-08-01T08:34:28

David Allouche said: The problem is in the "almost" and the "generally" ;-). *I* don't like this because of the extra cost of "Compute the local changes.". update already uses such kind of optimization to fall back to apply-delta strategy. In the short-term, I'll probably just remove my change, since your proposal is an optimization in a very particular case, and may be a pessimization in othe cases (if computing local changes is more costly than apply-delta).

Re: build-config, I need your opinion.

David Allouche — 2005-08-01T08:09:55

Re: build-config, I need your opinion.

Matthieu MOY — 2005-08-01T07:15:58

David Allouche said: Hmm, after thinking about it, I'm not sure this was a good idea: In terms of performance, it's cool, but it makes conflict handling really messy. What you find in the .rej file will be _your_ changes if the "update" optimization was applied, and the _merge source_ changes if it wasn't. Using "replay" instead of "update" would solve this problem, but would mean "switch" could stop before completion when it finds a conflict. 'wondering if the apply-delta was not actually the best solution...

Re: build-config, I need your opinion.

Matthieu MOY — 2005-08-01T08:34:28