Re: [Nix-dev] Re: new possible movement to git (?)
Hello, 2011/8/30 Peter Simons sim...@cryp.to: Yeah, it would be nice if git had information in commits about which branch the commit was initially performed on. This seems like a really simple feature, not sure why it doesn't exist. personally, I don't see why that information is relevant. Branch names are a local affair in Git. It's quite possible for two repositories to track the same content using completely different branch names. So why bother recording the name if it doesn't have any significance outside of the repository? Other DVCS make a lot of fuss about branch names, like monotone, but I don't see any gain in a distributed project. I'm very used to having branches and their names tracked by the VCS as part of the history. That's why I prefer approaches of fossil, svn, monotone, etc. over git. Otherwise, only the commit log may provide some context information about the circumstances of the change. So, I like having named branches tracked by the VCS, instead of simply having a big graph of file changes with commit logs with no additional information. And as for live public branches, as Raskin pointed out, the git (linux) people tend to simply stand a new repository for that specific purpose somewhere I'm also quite against of the possibility of rebasing, as it can easily make invalid assertions people may want to write in their logs, like I've tested the feature and it works. Then there is the untracked editing of commits, and all that related to history rewriting to the taste of the publisher, instead of keeping track of events in their context along time. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Shea, The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. But stdenv-updates isn't meant as a really big topic branch. It's meant as a place for changes that will require rebuilding the system, so we can minimize the number of times we require that. How does git help with that? Suppose that I modify GNU Make, for example, then that change ought to go into stdenv-updates. At the same time, you modify glibc, and that change goes into stdenv-updates, too. But those two changes are orthogonal. They don't depend on each other. So why should they be checked into the same branch? There is no conceptual reason to do that. Rather, there is a practical reason, namely the fact that creating two new branches for those two changes -- a.k.a. topic branches -- would be unfeasible with SVN. When using Git, that restriction no longer exists. I can create a branch stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra could build both of them (in fact, Hydra would probably build all stdenv/* branches). In that scenario, other users are free to merge the contents of either branch into their personal master; they can choose whether they want to have the latest gnu make or the latest glibc or both. When both changes are checked into one monolithic stdenv-updates branch, however, doing that is not so easy. Eventually, you decide that the new glibc is stable, and then you run git merge stdenv-updates on whatever happens to be your equivalent of the official master branch, and then you push the changeset upstream, which effectively makes them stable for everyone. The merge commit would even record the fact that you worked on a topic branch prior to that, and the history of that branch would become visible in master, too. The workflow is not completely different from what we are doing now, but the granularity is much higher. There isn't just one stdenv-updates branch. Rather, there are many of them. Basically, all branches except master are considered unstable, i.e. work in progress. When they have become stable, though, then they are pushed into the master branch. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com 87ei034yse@write-only.cryp.to 5833f9f3-bf70-4cae-9ad2-489170ad5...@email.android.com) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 But stdenv-updates isn't meant as a really big topic branch. It's meant as a place for changes that will require rebuilding the system, so we can minimize the number of times we require that. How does git help with that? Suppose that I modify GNU Make, for example, then that change ought to go into stdenv-updates. At the same time, you modify glibc, and that change goes into stdenv-updates, too. But those two changes are orthogonal. They don't depend on each other. So why should they be checked into the same branch? There is no conceptual reason to do that. Rather, there is a practical reason, namely the fact that creating two new branches for those two changes -- a.k.a. topic branches -- would be unfeasible with SVN. If it were, creating stdenv-updates per se would be infeasible. When using Git, that restriction no longer exists. I can create a branch stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra could build both of them (in fact, Hydra would probably build all stdenv/* branches). In that scenario, other users are free to merge the No. The space required could grow too fast. It was stated many times that Hydra jobsets will only be created by people running Hydra. contents of either branch into their personal master; they can choose whether they want to have the latest gnu make or the latest glibc or both. When both changes are checked into one monolithic stdenv-updates branch, however, doing that is not so easy. The problem is a packaging problem, not version-management one. If you update Make, a lot of packages break. If you update glibc, a lot of packages break. Some packages break only when you update both at once (nobody knows how they manage this). Also, you want to minimize big rebuilds. Note how stdenv-updates really goes: we update _many_ things at once, and then fix the bugs that show up with all the latest things. If we create small topic branches, we have a large risk of spending duplicated effort fixing many things on many topic branches, then merging some of the topic branches together and fixing more things that depend on combinations of versions, finding out the old fixes make things worse, and so on. Eventually, you decide that the new glibc is stable, and then you run git merge stdenv-updates on whatever happens to be your equivalent of the official master branch, and then you push the changeset upstream, which effectively makes them stable for everyone. The merge commit would even record the fact that you worked on a topic branch prior to that, and the history of that branch would become visible in master, too. Right, and the make change keeps hanging. So we are worse off than now, because we get two stdenv rebuilds. The workflow is not completely different from what we are doing now, but the granularity is much higher. There isn't just one stdenv-updates branch. Rather, there are many of them. Any update will require lots of fixes. So, it is better to have one stdenv branch, not ten 50%-broken branches. And by the way, having all glibc-update branches called the same even keeps the problem with Git history. Basically, all branches except master are considered unstable, i.e. work in progress. When they have become stable, though, then they are pushed into the master branch. For packaging, notion of stable cannot be preserved across merges with any kind of confidence.. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Hi Peter, I don't think this accurately reflects the reasons we use stdenv-updates. We don't put it all in the same branch because more fine-grained branching is expensive, we put it all in the same branch because we want the eventual merge of the changes to happen at the same time. We will still have that requirement for the public nixpkgs repo if we switch to git. ~Shea Hi Shea, The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. But stdenv-updates isn't meant as a really big topic branch. It's meant as a place for changes that will require rebuilding the system, so we can minimize the number of times we require that. How does git help with that? Suppose that I modify GNU Make, for example, then that change ought to go into stdenv-updates. At the same time, you modify glibc, and that change goes into stdenv-updates, too. But those two changes are orthogonal. They don't depend on each other. So why should they be checked into the same branch? There is no conceptual reason to do that. Rather, there is a practical reason, namely the fact that creating two new branches for those two changes -- a.k.a. topic branches -- would be unfeasible with SVN. When using Git, that restriction no longer exists. I can create a branch stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra could build both of them (in fact, Hydra would probably build all stdenv/* branches). In that scenario, other users are free to merge the contents of either branch into their personal master; they can choose whether they want to have the latest gnu make or the latest glibc or both. When both changes are checked into one monolithic stdenv-updates branch, however, doing that is not so easy. Eventually, you decide that the new glibc is stable, and then you run git merge stdenv-updates on whatever happens to be your equivalent of the official master branch, and then you push the changeset upstream, which effectively makes them stable for everyone. The merge commit would even record the fact that you worked on a topic branch prior to that, and the history of that branch would become visible in master, too. The workflow is not completely different from what we are doing now, but the granularity is much higher. There isn't just one stdenv-updates branch. Rather, there are many of them. Basically, all branches except master are considered unstable, i.e. work in progress. When they have become stable, though, then they are pushed into the master branch. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Shea, I don't think this accurately reflects the reasons we use stdenv-updates. We don't put it all in the same branch because more fine-grained branching is expensive, we put it all in the same branch because we want the eventual merge of the changes to happen at the same time. exactly who is we? Please speak for yourself. I, for one, do not want unrelated changes to be merged in one commit, because that habit breaks extremely useful tools such as git bisect. Besides, having many different stdenv/* topic branches does not imply that each of them must be merged into master separately. You *can* merge them all at once, of course, if you want to. It just so happens that I wouldn't want to do that because the practice violates elementary principles software engineering. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Hi Shea, I don't think this accurately reflects the reasons we use stdenv-updates. We don't put it all in the same branch because more fine-grained branching is expensive, we put it all in the same branch because we want the eventual merge of the changes to happen at the same time. exactly who is we? Please speak for yourself. I, for one, do not want unrelated changes to be merged in one commit, because that habit breaks extremely useful tools such as git bisect. Besides, having many different stdenv/* topic branches does not imply that each of them must be merged into master separately. You *can* merge them all at once, of course, if you want to. It just so happens that I wouldn't want to do that because the practice violates elementary principles software engineering. Do you see why there are benefits, if not from a developer's perspective, from an end-user perspective and from hydra's perspective to having changes to stdenv be infrequent and more inclusive than is appropriate for a generic feature branch? Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Michael, Eventually, you decide that the new glibc is stable, and then you run git merge stdenv/glibc on whatever happens to be your equivalent of the official master branch, and then you push the changeset upstream, which effectively makes them stable for everyone. Right, and the make change keeps hanging. So we are worse off than now, because we get two stdenv rebuilds. actually, it's exactly the opposite. We are better off because we have significantly reduced the amount of inference between changes to GNU Make and changes to GNU libc. When the glibc update has been pushed, those changes become stable or official or however you want to call it, meaning that those changes are going to be propagated into all active stdenv/* topic branches, where the people working on those branches can address problems the glibc update might cause locally. If all these changes were to occur in a single branch, then those changes would constantly interfere with each other, causing lots and lots of unnecessary re-builds and making everyone's live much harder. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Shea, Do you see why there are benefits [...] to having changes to stdenv be infrequent and more inclusive than is appropriate for a generic feature branch? of course, I totally agree with that. Stdenv should be changed only when there is a good technical reason to do so. For example, it's one thing to have the latest version of GNU Make available in nixpkgs, but it's another quite thing to put it into stdenv ... or bootstrap-tools. :-) Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Hi Shea, Do you see why there are benefits [...] to having changes to stdenv be infrequent and more inclusive than is appropriate for a generic feature branch? of course, I totally agree with that. Stdenv should be changed only when there is a good technical reason to do so. For example, it's one thing to have the latest version of GNU Make available in nixpkgs, but it's another quite thing to put it into stdenv ... or bootstrap-tools. :-) Ok, so when we have updated Make and gcc and glibc and all of that in nixpkgs, and we want to test it all together and give hydra something to build before we actually update stdenv to use the new tools, why not use a branch specifically made for this purpose? ~Shea Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[***SPAM***] [Nix-dev] Re: new possible movement to git (?)
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com 87ei034yse@write-only.cryp.to 5833f9f3-bf70-4cae-9ad2-489170ad5...@email.android.com 87ei03aw6p@write-only.cryp.to 894aedf1c3c6d28c2272e35ab266d932.squir...@webmail.shealevy.com) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 I don't think this accurately reflects the reasons we use stdenv-updates. We don't put it all in the same branch because more fine-grained branching is expensive, we put it all in the same branch because we want the eventual merge of the changes to happen at the same time. exactly who is we? Please speak for yourself. I, for one, do not want unrelated changes to be merged in one commit, because that habit breaks extremely useful tools such as git bisect. One commit and one branch are different things. Besides, having many different stdenv/* topic branches does not imply that each of them must be merged into master separately. You *can* merge them all at once, of course, if you want to. It just so happens that I wouldn't want to do that because the practice violates elementary principles software engineering. The problem is that actually merging them one-by-one is costly. Trunk should receive one rebuild. And it is established practice to reduce the count of stdenv rebuilds. Also, there is little happening in NixPkgs that should be classified as software engineering. Everything non-trivial in packaging is about finding out upstream quirks. To run NixOS, I need maximum amount of packages in stdenv-updates to be non-broken. Tracking what is broken where across five topic branches is insanity even without second-guessing what will start working on merge. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
e1qy7ah-0002y4-00.7c6f434c-mail...@smtp6.mail.ru e1qyojz-0005ym-00.7c6f434c-mail...@smtp1.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 Eventually, you decide that the new glibc is stable, and then you run git merge stdenv/glibc on whatever happens to be your equivalent of the official master branch, and then you push the changeset upstream, which effectively makes them stable for everyone. Right, and the make change keeps hanging. So we are worse off than now, because we get two stdenv rebuilds. actually, it's exactly the opposite. We are better off because we have significantly reduced the amount of inference between changes to GNU Make and changes to GNU libc. When the glibc update has been pushed, those changes become stable or official or however you want to call it, meaning that those changes are going to be propagated into all active stdenv/* topic branches, where the people working on those branches can address problems the glibc update might cause locally. If all these changes were to occur in a single branch, then those changes would constantly interfere with each other, causing lots and lots of unnecessary re-builds and making everyone's live much harder. Everyone is using trunk on the computers which they expect to work. So two stdenv rebuilds where one would work is an annoyance. The changes from glibc and from make would interfere once. We would rebuild make, then learn to build glibc with new make (we have to do this anyway), then make and glibc are quite likely not to change. Solutions to many problems with updates often include updating the offending packages to get upstream fixes. Your way supposes trying to build them with just new glibc, and then trying to build them with new glibc and make. It doesn't look like this approach would reduce rebuilds. And, by the way, if updating a package to a new-and-shiny version which boasts fixed problems with fresh glibc also requires fresh gcc, won't it lead either to consiously breaking trunk or to making glibc-updates branch closer to stdenv-updates anyway? Updating GNU TLS to 3.0 seems to make need GTK+-3.0 packages for glib-networking to work. It is just a fresh example... ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Shea, [We] have updated Make and gcc and glibc and all of that in nixpkgs, and we want to test it all together and give hydra something to build before we actually update stdenv to use the new tools, why not use a branch specifically made for this purpose? sure, I guess that's exactly what we are going to do. Now, suppose we have updates of make, glibc, and gcc. The updates to glibc and gcc work just fine, but the update to make breaks half of all our builds. Do you think we should defer the updates to glibc and gcc until all failures caused by the new make have been fixed? Or do you think we might want to update glibc and gcc in 'master', and continue to work on the make issue independently? Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi! Eelco Dolstra e.dols...@tudelft.nl skribis: So it would be nice if we had a more stable tree that users can update from safely. For example, we could have these Nixpkgs/NixOS trees/branches: - An unstable tree which receives developer commits. It might be in a broken state, so end users shouldn't use it. Hydra continuously builds it. Of course, complicated changes should be done in a feature tree/branch and pulled in when they're done. - A tested tree that automatically gets updated from the unstable tree when some set of Nixpkgs and NixOS tests succeed *and* the Nixpkgs channel is up to date. This tree should be fairly safe to use. - A stable tree that gets updated manually and conservatively (e.g., only security or stability updates). Does this sound reasonable? Sounds like a great idea. Automatic migration from ‘unstable’ to ‘tested’ may be tricky to implement, but it would be really nice (this reminds me of ‘tla-pqm’, an automatic patch queue manager [0].) [...] Random point: should the NixOS and Nixpkgs trees be in the same repository? I think so, since it allows them to be updated atomically, which is important given that Nixpkgs and NixOS changes are often related. Agreed. Thanks, Ludo’. [0] http://wiki.bazaar.canonical.com/PatchQueueManager ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Michael, Two stdenv rebuilds where one would work is an annoyance. [...] Your way supposes trying to build them with just new glibc, and then trying to build them with new glibc and make. It doesn't look like this approach would reduce rebuilds. [...] my impression is that we approach the question at hand using different priorities. You seem to be concerned mostly with Hydra, i.e. you argue that policies should be designed so that Hydra is happy, whereas I am concerned with people, i.e. I argue for policies that simplify development -- even if this means that Hydra has to perform builds that could theoretically have been avoided. Under those circumstances, I don't see how we could agree, so I suggest we agree to disagree. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
87ei03aw6p@write-only.cryp.to e1qyq0p-0003fq-00.7c6f434c-mail...@smtp15.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 Two stdenv rebuilds where one would work is an annoyance. Your way supposes trying to build them with just new glibc, and then trying to build them with new glibc and make. It doesn't look like this approach would reduce rebuilds. my impression is that we approach the question at hand using different priorities. You seem to be concerned mostly with Hydra, i.e. you argue that policies should be designed so that Hydra is happy, whereas I am concerned with people, i.e. I argue for policies that simplify development -- even if this means that Hydra has to perform builds that could theoretically have been avoided. Well, I'd say that I care more about people using Nix, because usually I use way more packages than dependencies of any given package (which I would rebuild while developing a package). Also, not everything I use is built by Hydra... Also, looks like state of the affairs in the parts of Nixpkgs we work on is too different. I could look for some examples where updating sanely meant simply updating everything first and sorting things out later; there obviously are some updates where knowing whether new glibc or new gcc breaks the build helps. I guess getting any numbers would be hard. Under those circumstances, I don't see how we could agree, so I suggest we agree to disagree. Well, I am even more unconvinced - based on my experience with updates, I would prefer stdenv-updates to be unified branch even for the process of fixing the packages. Because easy things are just done and hard things are - in my experience with packaging - usually easy to trace back to single dependency and hard to fix anyway. But you are right, it's not likely that we could find any new arguments. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On Tue, Aug 30, 2011 at 08:12:33PM +0400, Michael Raskin wrote: Under those circumstances, I don't see how we could agree, so I suggest we agree to disagree. Well, I am even more unconvinced - based on my experience with updates, I would prefer stdenv-updates to be unified branch even for the process of fixing the packages. Because easy things are just done and hard things are - in my experience with packaging - usually easy to trace back to single dependency and hard to fix anyway. I think I'm with Michael about having stdenv-updates. I like the current process of updating stdenv pieces, and at some point, decide on stabilisation, freeze updates, and fix any problems there may be. Before stabilisation, we may have some packages (or even platforms) not working, but still a big part working for others to play with stdenv. This does not mean that people may want to branch from stdenv-updates to fix or update some pieces, but I'd have hydra busy building only stdenv-updates, for example. Just to have a single point where people caring about stdenv can take a look and see the status, and what can be done. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi Lluís, I would have Hydra build only stdenv-updates. in that case, I am glad that this decision is not up to you. Based on http://hydra.nixos.org/project/nixpkgs, I have faith that the people who do make those kind of decisions don't agree with your point of view. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On Tue, Aug 30, 2011 at 07:34:36PM +0200, Peter Simons wrote: Hi Lluís, I would have Hydra build only stdenv-updates. in that case, I am glad that this decision is not up to you. Based on http://hydra.nixos.org/project/nixpkgs, I have faith that the people who do make those kind of decisions don't agree with your point of view. Ah, well, I wrote too short what I meant. I mean that I think hydra would be most useful to us if it does not bother building constantly short-lived branches. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi, Given that branches are mere pointers, I don't see how to find out what was stdenv-updates before after it has been merged into trunk and re-created Yeah, it would be nice if git had information in commits about which branch the commit was initially performed on. This seems like a really simple feature, not sure why it doesn't exist. personally, I don't see why that information is relevant. Branch names are a local affair in Git. It's quite possible for two repositories to track the same content using completely different branch names. So why bother recording the name if it doesn't have any significance outside of the repository? Other DVCS make a lot of fuss about branch names, like monotone, but I don't see any gain in a distributed project. The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. Also, I'm not quite sure why there should be an extra stable branch. As far as I am concerned, master ought to be stable. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
On 30/08/11 00:51, Peter Simons wrote: Hi, Given that branches are mere pointers, I don't see how to find out what was stdenv-updates before after it has been merged into trunk and re-created Yeah, it would be nice if git had information in commits about which branch the commit was initially performed on. This seems like a really simple feature, not sure why it doesn't exist. personally, I don't see why that information is relevant. Branch names are a local affair in Git. It's quite possible for two repositories to track the same content using completely different branch names. So why bother recording the name if it doesn't have any significance outside of the repository? Other DVCS make a lot of fuss about branch names, like monotone, but I don't see any gain in a distributed project. The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. if you want branch to show in history you would have to push that branch ti remote repo as well (using --no-ff option). but as Peter pointed, branches in git are matter of local higene. You name it however you want and make sure you merge them to remote branch. Git doesn't force to you specific branching policy localy while still playing nice with policy used on remote branch. Also, I'm not quite sure why there should be an extra stable branch. As far as I am concerned, master ought to be stable. Or master is unstable and there is stable branch. As long as its documented what is where it doesn't really matter. Maybe master being stable makes more sense since usually newcomers always look there and considered its stable they will have better first time experience (or maybe this is not wanted :P). ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Peter Simons sim...@cryp.to wrote: Hi, Given that branches are mere pointers, I don't see how to find out what was stdenv-updates before after it has been merged into trunk and re-created Yeah, it would be nice if git had information in commits about which branch the commit was initially performed on. This seems like a really simple feature, not sure why it doesn't exist. personally, I don't see why that information is relevant. Branch names are a local affair in Git. It's quite possible for two repositories to track the same content using completely different branch names. So why bother recording the name if it doesn't have any significance outside of the repository? Other DVCS make a lot of fuss about branch names, like monotone, but I don't see any gain in a distributed project. The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. But stdenv-updates isn't meant as a really big topic branch. It's meant as a place for changes that will require rebuilding the system, so we can minimize the number of times we require that. How does git help with that? Also, I'm not quite sure why there should be an extra stable branch. As far as I am concerned, master ought to be stable. Some people desire the ability to expect most packages to build, some to use the latest packages. These desires are often in tension. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 Hi, Given that branches are mere pointers, I don't see how to find out what was stdenv-updates before after it has been merged into trunk and re-created Yeah, it would be nice if git had information in commits about which branch the commit was initially performed on. This seems like a really simple feature, not sure why it doesn't exist. personally, I don't see why that information is relevant. Branch names are a local affair in Git. It's quite possible for two repositories to So large projects model persistent branches with separate repositories, and still cannot keep track of what went where in the first place. track the same content using completely different branch names. So why bother recording the name if it doesn't have any significance outside of This is sometimes reverse thinking. What you say is Git doesn't provide nice tools to work with global branches, so they are useless. In Linux, separate feature branches are global and persistent. They use separate repositories to distribute load and because Git doesn't give them anything else. In Mozilla separate branches follow a naming system and live inside one repository. We do want long-lived global feature branches - if not, why not simply have SVN as the main repo and use whatever system you prefer for tracking local changes? Because SVN does allow global bracnhes? Mercurial used to have way of dealing with branches similar to what you described; they allowed keeping more data about intentions to fix the interface. Git makes complete format stability one of its ways to ensure overall reliability of the system, so it is unlikely Git will allow to store any new kinds of information about commits in-repo. the repository? Other DVCS make a lot of fuss about branch names, like monotone, but I don't see any gain in a distributed project. Monotone promotes a consistent culture of naming branches. The basic things that come from that is that I can sensibly manage one Monotone database and make checkouts of whatever project I need when I need them. The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. Well, we could call our stdenv-updates branches add-glibc-2.7 etc. We didn't do it as a matter of development organization, not because of some VCS matter. It is impossible to make stdenv-updates branch small if you want anything to work after the merge - even GNU TLS updates often break some networking applications; gcc updates require rechecking most other packages. Sometimes it is prefereable to update many packages and then wait for upstream fixes in some more. So this branch will not be short-lived - most probably, neither in days nor in commits. Stdenv-updates has a few meanings conveying developer intent: first, it is a branch where full-rebuild updates go; second, Hydra has a task to build stdenv-updates branch; its static name means that the task is simply switched on and off, not changed every time. That way there is less place for mistakes - and so less burden for Hydra maintenance. Also, I'm not quite sure why there should be an extra stable branch. As far as I am concerned, master ought to be stable. You either shift the problem or understand it not in a way others do. There is some code line that is build by Hydra and that is hoped to be somewhat stable. Currently it is trunk. So people simply translate it as master. It is unlikely that every revision of it allows to build every package in some checklist including Firefox and OpenOffice. Simply because mistakes do happen and there is no way to ensure that a well-tested update of some package doesn't cause some part of dependent packages to fail. Next, there is a stream of commits which were actually built by Hydra. Git doesn't allow tracking it all inside VCS, but the latest can be the head of some auto-shifted branch or bear some tag. Next, there could be some way to get the latest commits that, say, make a few NixOS feature-tests pass. The stable branch discussed in this thread consists of hand-picked commits that pass all formal tests and do not cause noticeable problems in actual use. Once can want master to be that stable branch or one may want to have a separate stable branch - but the question of hand-picking stays. There is also a question of what formal criteria to set if we want Hydra-related branches, too. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[***SPAM***] [Nix-dev] Re: new possible movement to git (?)
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com 87ei034yse@write-only.cryp.to) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 The whole notion of having a stdenv-updates branch in the first place is obsolete in Git. Instead, we would have many small topic branches for specific features. if you want branch to show in history you would have to push that branch ti remote repo as well (using --no-ff option). but as Peter pointed, branches in git are matter of local higene. You name it however you want and make sure you merge them to remote branch. Git doesn't force to you specific branching policy localy while still playing nice with policy used on remote branch. Well, remote branches are just local branches for the remote repository. So the naming questions apply to them. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On 08/26/2011 12:28 AM, Rok Garbas wrote: On 24/08/11 23:02, Shea Levy wrote: It has been over a year since this discussion and I have not seen any move toward implementing the suggestions in the thread. If this is simply due to inertia, I would like to offer up help similar to what Marc Weber offers in his initial email (migrating scripts, providing advice to users, etc.). If it is because the NixOS community is undecided as to which vcs to switch to, perhaps we should have a discussion about how to fairly discuss and decide such things? i think its one of those things nobody wants take over them since - as usually is - migration svn-to-git is usually pain or at least time consuming. i'm just finishing fairly large migration (3 separate svn-repos, ~300k commits, first commit dates to 2004, not to mention all svn cp that happened over time, kde's svn2git is used) and i could use this experience (writing complex svn2git rules) and migrate nixos svn repository to more github repos (i assume you want to split some things out) i would suggest that if there is interest that we just do migration - it might not even be that painful - then it would be easier to make decision since keeping this up-to-date is a matter of few extra cpu cycles per hour. garbas on freenode, in case you would be interested in my help. what i would need to get started is **idea what should go where** and somebody giving me instructions. see you on irc... lp rok ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev From my thinking, the process would be cleanest if it took the following steps: 1. All the projects which contain references to the svn repos get updated to point to where the new git repos will be 2. The svn repo is rendered read-only or all committers have their write access revoked 3. Git repos are generated from the svn repos (each of the https://svn.nixos.org/repos/nix/*) using one of the many available tools for the purpose 4. The newly-generated git repos are put in the locations specified in step 1. Anyone can perform steps 1 and 3, while steps 2 and 4 require some sort of administrative access to complete, but are fairly straightforward in and of themselves. If we can get agreement about where the git repos should go, I'll be happy to perform steps 1 and 3 (and 4, if we decide to host the git repos somewhere public or on my servers for some reason) myself, but without agreement on step 1 any effort on this will just be wasted since everything will still default to the svn.nixos.org repos. I'm a bit tempted to just say If I get no objections by two weeks from now, I'll update the svn to point to a github repo until someone can set the repos up on the nixos servers, but I don't know whether the policy for a change this big is if nothing is said, do it or if nothing is said, don't do it. ~Shea ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hi guys, personally, I would like to see a move to Git happen just as much as you do, mostly because daily operations with Git are much faster than they are with SVN (at least for me, that is). However, there isn't much of a point getting ahead of ourselves, planning the details of the move until Eelco has said that he actually wants that. Until now, he hasn't. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
j377eb$m52$1...@dough.gmane.org) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 From my thinking, the process would be cleanest if it took the following steps: 1. All the projects which contain references to the svn repos get updated to point to where the new git repos will be 2. The svn repo is rendered read-only or all committers have their write access revoked 3. Git repos are generated from the svn repos (each of the https://svn.nixos.org/repos/nix/*) using one of the many available tools for the purpose 4. The newly-generated git repos are put in the locations specified in step 1. Anyone can perform steps 1 and 3, while steps 2 and 4 require some sort of administrative access to complete, but are fairly straightforward in and of themselves. If we can get agreement about where the git repos should go, I'll be happy to perform steps 1 and 3 (and 4, if we decide to host the git repos somewhere public or on my servers for some reason) myself, but without agreement on step 1 any effort on this will just be wasted since everything will still default to the svn.nixos.org repos. I'm a bit tempted to just say If I get no objections by two weeks from now, I'll update the svn to point to a github repo until someone can set the repos up on the nixos servers, but I don't know whether the policy for a change this big is if nothing is said, do it or if nothing is said, don't do it. ~Shea We have if nothing is said, don't do it for far less intrusive changes than changes that include loss of access to some parts of data. With SVN I can easily look up which commits were initially done in stdenv branch and which were done in trunk. Ditto with Mercurial. But with git you seem to need some extra knowledge to do that after the proposed move. There are many arguments for hg/fossil/git, so just moving to git is not obviously the best solution. There are things that are better in SVN than in git, and we are not a kernel-sized project where we would be in the situation git is tuned for. So it is not a good idea to do any radical step without explicit support from TU Delft people. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On 08/26/2011 07:36 AM, Michael Raskin wrote: j377eb$m52$1...@dough.gmane.org) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 From my thinking, the process would be cleanest if it took the following steps: 1. All the projects which contain references to the svn repos get updated to point to where the new git repos will be 2. The svn repo is rendered read-only or all committers have their write access revoked 3. Git repos are generated from the svn repos (each of the https://svn.nixos.org/repos/nix/*) using one of the many available tools for the purpose 4. The newly-generated git repos are put in the locations specified in step 1. Anyone can perform steps 1 and 3, while steps 2 and 4 require some sort of administrative access to complete, but are fairly straightforward in and of themselves. If we can get agreement about where the git repos should go, I'll be happy to perform steps 1 and 3 (and 4, if we decide to host the git repos somewhere public or on my servers for some reason) myself, but without agreement on step 1 any effort on this will just be wasted since everything will still default to the svn.nixos.org repos. I'm a bit tempted to just say If I get no objections by two weeks from now, I'll update the svn to point to a github repo until someone can set the repos up on the nixos servers, but I don't know whether the policy for a change this big is if nothing is said, do it or if nothing is said, don't do it. ~Shea We have if nothing is said, don't do it for far less intrusive changes than changes that include loss of access to some parts of data. With SVN I can easily look up which commits were initially done in stdenv branch and which were done in trunk. Ditto with Mercurial. But with git you seem to need some extra knowledge to do that after the proposed move. There are many arguments for hg/fossil/git, so just moving to git is not obviously the best solution. There are things that are better in SVN than in git, and we are not a kernel-sized project where we would be in the situation git is tuned for. So it is not a good idea to do any radical step without explicit support from TU Delft people. Yeah, I won't actually do anything without an explicit go-ahead, though I'll really want to if this discussion just dies out without any resolution like the last time this came up. As to the git is not obviously the best solution: this is why I wanted to revive this discussion. Please, let's discuss the relative merits of different SCM options. Obviously ultimately the TU Delft people are ultimately in control of this project, but to the extent that we want decisions like these to be handled by the community: If the answer to why haven't we switched away from svn is simply inertia, then we should discuss how to overcome that inertia. If the answer is that we might want to stick with svn, or that we might want to switch to something besides git, then we should discuss the reasons for and against, and if we can't come to an obvious solution than maybe we should take a step back and discuss how decisions like this should be made. I'm not saying nixos needs formal processes or anything, but this was discussed last year and seems to have a fair amount of support but has never been resolved. I am pushing for git because it is from my (admittedly limited) knowledge the best solution, but what I care about more than that is making some move on this issue. That could mean Eelco saying that he's going to stick with subversion and that's that, it could mean a consensus that it is too difficult to choose which system to switch to so subversion wins by default, it could mean a consensus that we should table this discussion for a fixed period of time, etc. The current situation is a bit frustrating, though, since we have people willing to do the work involved but no definitive answer either way, even though those who have the authority to give a definitive answer have commented on the matter. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On 08/26/2011 06:34 AM, Peter Simons wrote: Hi guys, personally, I would like to see a move to Git happen just as much as you do, mostly because daily operations with Git are much faster than they are with SVN (at least for me, that is). However, there isn't much of a point getting ahead of ourselves, planning the details of the move until Eelco has said that he actually wants that. Until now, he hasn't. Take care, Peter ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev My hope in giving the possible details is to make the prospective move seem as work-free for most people as possible to overcome any inertia that remains. Of course, if there is more than simple inertia stopping the move, then having a planned process won't help. ~Shea ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Hi Michael, On Fri, Aug 26, 2011 at 13:36, Michael Raskin 7c6f4...@mail.ru wrote: With SVN I can easily look up which commits were initially done in stdenv branch and which were done in trunk. Ditto with Mercurial. But with git you seem to need some extra knowledge to do that after the proposed move. I agree, but only If you use rebase. git rebase is nice for local branches, but is a nightmare when you are working a large number of persons. In git cherry-picks are not tracking the patch history. Thus you cannot rely on cherry-pick with git as you do with subversion. The other mean is to use merges, which keep the history as it is. Thus you can see that this was a previous branch which has been merged into the master (trunk) Changing VCS also implies to change the workflow which is based on it. Having used git / hg / svn, I really love to be able to seek the history very fast, which is really slow in hg and svn. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Hello, Shea Levy s...@shealevy.com skribis: If it is because the NixOS community is undecided as to which vcs to switch to, perhaps we should have a discussion about how to fairly discuss and decide such things? I think it’s mostly because the maintainer is undecided. :-) Ludo’. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
l...@gnu.org wrote: Hello, Shea Levy s...@shealevy.com skribis: If it is because the NixOS community is undecided as to which vcs to switch to, perhaps we should have a discussion about how to fairly discuss and decide such things? I think it’s mostly because the maintainer is undecided. :-) Fair enough, as I said those if-then scenarios only apply to the extent that Eelco wants this kind of decision to be managed by the community. If he is undecided though, I'd be interested in discussing why, or, if he isn't interested in having the discussion, I'd appreciate knowing that so we have some sort of answer. Ludo’. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
4e5566e6.9050...@shealevy.com 4e576c9c.4010...@shealevy.com e1qwubl-0003wo-00.7c6f434c-mail...@smtp15.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 On Fri, Aug 26, 2011 at 13:36, Michael Raskin 7c6f4...@mail.ru wrote: With SVN I can easily look up which commits were initially done in stdenv branch and which were done in trunk. Ditto with Mercurial. But with git you seem to need some extra knowledge to do that after the proposed move. I agree, but only If you use rebase. git rebase is nice for local branches, but is a nightmare when you are working a large number of persons. Any change in the history is a nightmare when you have more than one repository that had the original history. That's fine In git cherry-picks are not tracking the patch history. Thus you cannot rely on cherry-pick with git as you do with subversion. The other mean is to use merges, which keep the history as it is. Thus you can see that this was a previous branch which has been merged into the master (trunk) As far as I remember, you need to keep old branch head at the position where it was merged for this to work. Unlike hg and monotone, commit doesn't remember its branch per se and you cannot store the branch where commit belongs automatically. This means that after conversion we will lose data, because we have multiple merges of branch stdenv to trunk. Also, if you have branches that later split in branches and are merged directly into master, you cannot automatically find out which of the branches was created only during split. Changing VCS also implies to change the workflow which is based on it. Having used git / hg / svn, I really love to be able to seek the history very fast, which is really slow in hg and svn. Frankly, I tried multiple DVCSes (I used hg, bzr and mtn for a lot of time and sent some patches to git-managed projects) and git makes most stress on managing huge projects and least stress on having a nice straightforward conceptual system that covers all operations (or on keeping all data it has now in future). ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
On 24/08/11 23:02, Shea Levy wrote: It has been over a year since this discussion and I have not seen any move toward implementing the suggestions in the thread. If this is simply due to inertia, I would like to offer up help similar to what Marc Weber offers in his initial email (migrating scripts, providing advice to users, etc.). If it is because the NixOS community is undecided as to which vcs to switch to, perhaps we should have a discussion about how to fairly discuss and decide such things? i think its one of those things nobody wants take over them since - as usually is - migration svn-to-git is usually pain or at least time consuming. i'm just finishing fairly large migration (3 separate svn-repos, ~300k commits, first commit dates to 2004, not to mention all svn cp that happened over time, kde's svn2git is used) and i could use this experience (writing complex svn2git rules) and migrate nixos svn repository to more github repos (i assume you want to split some things out) i would suggest that if there is interest that we just do migration - it might not even be that painful - then it would be easier to make decision since keeping this up-to-date is a matter of few extra cpu cycles per hour. garbas on freenode, in case you would be interested in my help. what i would need to get started is **idea what should go where** and somebody giving me instructions. see you on irc... lp rok signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
On 26/08/11 06:28, Rok Garbas wrote: repository to more github repos (i assume you want to split some things out) that should be git signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Re: new possible movement to git (?)
Marc Weber wrote: I still see the value of SVN checkouts - less size on disk - so maybe % cd /etc/nixos/nixpkgs # git checkout, both trunk and stdenv branch % git gc; du -sh 66M % du -sh .git 41M # Hence, the tree is 66-41=25M % du -sh /etc/nixos/nixpkgs-svn 130M Are you still sure that svn checkout use less disk space? But I think that we should discuss the choice of dvcs (or setup some autosynced dvcs mirrors). I know that Michael Raskin is against git. Eelco, could you please provide svn dump? I'd like to test svn2git script used by KDE. maintaining a svn mirror (for stable branch only?) is a good choice? At this point I want to remind that github has a SVN interface for git repositories! Thus you can use git - but SVN users can still use SVN if they prefer. I haven't tested it yet - though. I'm against using external closed source code hosting. Eelco Dolstra: Thanks for taking the time to reply. Let me know if I can support you in any way, please. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
Excerpts from Yury G. Kudryashov's message of Wed Aug 04 13:23:10 +0200 2010: But I think that we should discuss the choice of dvcs (or setup some autosynced dvcs mirrors). I know that Michael Raskin is against git. We can. But I think the result will be git. Michael Raskin: If you'd prefer a different one say so - and say why, please. In a previous post I concluded that he would accept using git as alternative to SVN. See here: http://thread.gmane.org/gmane.linux.distributions.nixos/4425/focus=4440 I'm against using external closed source code hosting. It could be used as additional git mirror for that reason if there is need to. This could provide some additional transition time for some users. Is someone interested in it at all? I still see the value of SVN checkouts - less size on disk - so maybe % cd /etc/nixos/nixpkgs # git checkout, both trunk and stdenv branch % git gc; du -sh 66M % du -sh .git 41M # Hence, the tree is 66-41=25M % du -sh /etc/nixos/nixpkgs-svn 130M Are you still sure that svn checkout use less disk space? Is your comparison fair? Did you include the checked out files in the git calculation? Because SVN stores all files twice let's add 1/rd of the space of SVN. Then you have 40M + (130/4M) approx 80MB. Still less than 130MB. But I expect nixpkgs to grow. So in 10 years svn will be smaller because it doesn't store history. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
On Wednesday 04 August 2010 15:59:17 Marc Weber wrote: Excerpts from Yury G. Kudryashov's message of Wed Aug 04 13:23:10 +0200 2010: But I think that we should discuss the choice of dvcs (or setup some autosynced dvcs mirrors). I know that Michael Raskin is against git. We can. But I think the result will be git. Michael Raskin: If you'd prefer a different one say so - and say why, please. In a previous post I concluded that he would accept using git as alternative to SVN. See here: http://thread.gmane.org/gmane.linux.distributions.nixos/4425/focus=4440 I'm against using external closed source code hosting. It could be used as additional git mirror for that reason if there is need to. This could provide some additional transition time for some users. Is someone interested in it at all? I still see the value of SVN checkouts - less size on disk - so maybe % cd /etc/nixos/nixpkgs # git checkout, both trunk and stdenv branch % git gc; du -sh 66M % du -sh .git 41M # Hence, the tree is 66-41=25M % du -sh /etc/nixos/nixpkgs-svn 130M Are you still sure that svn checkout use less disk space? Is your comparison fair? Did you include the checked out files in the git calculation? Because SVN stores all files twice let's add 1/rd of the space of SVN. Then you have 40M + (130/4M) approx 80MB. Still less than 130MB. But I expect nixpkgs to grow. So in 10 years svn will be smaller because it doesn't store history. This isn't entirely correct because svn checkout will grow too unless you expect to only do version bumps. And 10 years??? svn won't last this long I'm afraid :) One of the reasons why SVN checkout of nixpkgs is so large is because of the code tree organization: most of dirs have just one 1kb file which means huge overhead for svn. Just look into .svn dirs. Just to make sure: %du nixpkgs/.git nixpkgs -s 42804 nixpkgs/.git 68912 nixpkgs and this is svn: % du nixpkgs2 -s 131964 nixpkgs2 -- Evgeny ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2010 04:59 PM, Marc Weber wrote: Excerpts from Yury G. Kudryashov's message of Wed Aug 04 13:23:10 +0200 2010: But I think that we should discuss the choice of dvcs (or setup some autosynced dvcs mirrors). I know that Michael Raskin is against git. We can. But I think the result will be git. Michael Raskin: If you'd prefer a different one say so - and say why, please. In a previous post I concluded that he would accept using git as alternative to SVN. See here: http://thread.gmane.org/gmane.linux.distributions.nixos/4425/focus=4440 I said about having a Git mirror being a good start in multi-VCS system. Storing repository in Git has some drawbacks, as it stores too little history. As far as I know with our branch/merge cycle for stdenv-updates, it would be impossible to find out which path was stdenv-updates and which was trunk except by counting distinct stdenvs on each path. I'm against using external closed source code hosting. It could be used as additional git mirror for that reason if there is need to. This could provide some additional transition time for some users. Is someone interested in it at all? Is there anyone using Tailor for Git-SVN? It may turn out to be easier... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWaGzAAoJEE6tnN0aWvw3daQH/3pZj7II5K+uzSxWqVeYoWFs K2sZ/FTv9AA/VSzW2ZXfIzkmtg3HYgnUf0taGadVg/PgSOcM2AMojCKkpt8DRXq1 H9suuY7z9LRhfNSJZNf/ADcNNsltX0VxfxhWXk9DMCKHM+XWn6cjVOf1c8M6gwiZ kG+T38xXiuo2mMiP8akQOyZaBxHOWhIkY04MIamZgQ6YZ21RZXBtaMq4ulD/9nOX QVVuuFH8odOypO2MjCRKw+4R+PraP1QgHZFzBLht/by6M3jgcUn6AE3FgGenJxOB geS2vxFUsXKqGJt7pJPau0TN+A5iUOrY2Zx3f408twNRADh2c3jWKoQ7YpawGSA= =rSql -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: new possible movement to git (?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2010 09:35 PM, Marc Weber wrote: Are you talking about merging? a - x -y - MERGE - ... `- B -C ` So that its hard to find out whether x - y or B - C was stdenv-updates? We could add a BRANCH-INFO file then and put the info in there. Well, if we want to do that, maybe we have to agree on the set of necessary kludges beforehand. Git *is* stupid by design. You could mark it by tagging as well tag-stdenv-updates-before-merge. Design? Git has no design, just speed optimizations. Look at Darcs for what a VCS design is. If we wish to use history as something more than unlabeled graph, we need to decide now - SVN to Git move can be a lossy operation. However git is different anyway. Probably we're not going to have stdenv-anymore. We'll have branches such as gtk-updates xorg-updates, ... and maybe a branch called next which is a merge of those topics. You understand that you are just strengthening my point? I understand that _any_ DVCS (probably even SVK) simplifies having lighter branches. But Git considers OK to GC branch data. And no, it is not ignoring historical branch data - as you claimed it does for simplicity - it stores reflog and can be made to clean it. I am not even sure how much of history rewriting is actually a good idea (as opposed to cherry-picking from a local branch/a local-only second head of the branch). Personally, I am promoting Monotone, as it has deliberately hard-to-lose history, commit property authentication (i.e. you know who set what tag), and also will allow us to have things like a branch (maybe discontinuous) of revisions fully processed by Hydra. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWchPAAoJEE6tnN0aWvw3ndQH/iRrNOqpR1uXglgmU3B1OK5P Frrtgdqd3Ai7wJ7gk+F24FHCsGlQaPFmzJhCrPn7nqzPsXgodAISVEHl5sczVP3o /DmYAPrHz7yPR6ANafZGk1QaiA+Z4XL5AYhPKcwjjnKNN0kwDqT+m0zReTcXwOA8 ybr865g2dju7YMf/XpJxBQBVBvniASVOIO/twwv9651Mnf/YtpTPmNnNAMSdHcyA MGs161jPpWbOIa7BFcLhheUue+8xf3S2qeTvAb4MGW1CA5RqBvjcxJdAG9PMzuMQ zgFOrS4x+LkHaPfhrmSZj2kHpfJGmt2M8iLfRxWvCE+l1voo8hc2LuUGNhSrX+g= =3Wwv -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
