Re: [boost] [git] neglected aspects
The only downside (I can see) with GIT is that it has a bit of a learning curve.
It is a bit more complicated but I believe (and experienced myself) that a lot of that learning curve is unnecessarily steep due to the way many of the tutorials out there are written. For some reason most of them start out describing the guts and inner workings of git (blobs, trees, packs, etc.) rather than teaching workflows. The one great exception I've found to this is Scott Chacon's fabulous _Pro_Git_ (http://progit.org/book). It teaches you how to use git to manage sources. Reading that is what make it "click" for me. -Dave
David A. Greene wrote:
guts and inner workings
i found http://help.github.com incredibly helpful to get going. it seems to come from the opposite side, though - i had my github account, the spoon-knife test repo and some project forks up and running within minutes, as that's mostly just mouse clicks on a website - but i still hadn't really grasped gits concepts. next, i wanted to change some code in projects i had forked. host:~ user$ git help --> gives an overview of what commands are available, many of them are familiar from svn or other VCSs host:~ user$ git help <command> --> explains <command> in detail i got a few minor things wrong the first time i tried them and i still have not seen everything git can do, but from my experience, most people will be up and running in git after half a day at the most. git is definitely easier to get your head around than some of the stuff done in some of the boost libraries ;-)
David A. Greene wrote:
The only downside (I can see) with GIT is that it has a bit of a learning curve.
It is a bit more complicated but I believe (and experienced myself) that a lot of that learning curve is unnecessarily steep due to the way many of the tutorials out there are written. For some reason most of them start out describing the guts and inner workings of git (blobs, trees, packs, etc.) rather than teaching workflows.
The one great exception I've found to this is Scott Chacon's fabulous _Pro_Git_ (http://progit.org/book). It teaches you how to use git to manage sources. Reading that is what make it "click" for me.
Git Immersion also offers a very gentle learning curve. http://gitimmersion.com/
Hi,
Stop right here. You seem to be writing this on the assumption that with git, we'd still have two separate source trees, one for the development branch and one for the release/master branch. One of the exciting things of git is exactly that you can abandon that situation. There is only one file tree, and the branches act like "parallel worlds" in which that same file tree received different update histories. So a feature branch is just another instance of the same tree, with the same available testing infrastructure.
For me branches in SVN match perfectly the git version you provide. When you create a branch it's the same "file tree" and then you can apply different patches on both (and then merge them back). Of course if the patches are add or remove files then file trees will differ, but I guess that this is the same for git. The differenc I see is that branches are a separate entity while in SVN they're a different leaf in the node above.
- The master branch corresponds to the current release branch, again with an important difference. In the current situation, trunk is merged directly into release, with the (manual) exception of libraries that are in too turbulent state, and after that the release branch is updated until everything is really ready for release. In the new situation, a new (temporary) release branch is forked from develop first (which automatically excludes turbulent changes because those reside in separate feature branches) and then updated until all tests pass (ideally), at which point it is finally merged into master (as well as back into develop). So the master branch only includes the actual releases, which of course are also tagged.
This doesn't fit in my small brain when I try to imagine it. Sorry :( I guess it's time people on both sides fire their slide editors so that I (and hopefully others) can have a better view of the problem and the solutions Julien
On 02/09/2012 04:10 PM, Julien Nitard wrote:
- The master branch corresponds to the current release branch, again with an important difference. In the current situation, trunk is merged directly into release, with the (manual) exception of libraries that are in too turbulent state, and after that the release branch is updated until everything is really ready for release. In the new situation, a new (temporary) release branch is forked from develop first (which automatically excludes turbulent changes because those reside in separate feature branches) and then updated until all tests pass (ideally), at which point it is finally merged into master (as well as back into develop). So the master branch only includes the actual releases, which of course are also tagged.
This doesn't fit in my small brain when I try to imagine it. Sorry :( I guess it's time people on both sides fire their slide editors so that I (and hopefully others) can have a better view of the problem and the solutions
This has pictures: http://nvie.com/posts/a-successful-git-branching-model/ Mika Heiskanen
Mika Heiskanen wrote:
On 02/09/2012 04:10 PM, Julien Nitard wrote:
[...]
This doesn't fit in my small brain when I try to imagine it. Sorry :( I guess it's time people on both sides fire their slide editors so that I (and hopefully others) can have a better view of the problem and the solutions
This has pictures:
A side-by-side visual comparison would probably be a good idea. I'm working on such a picture, I hope to send it tomorrow. -Julian
Julian Gonggrijp wrote:
Mika Heiskanen wrote:
On 02/09/2012 04:10 PM, Julien Nitard wrote:
[...]
This doesn't fit in my small brain when I try to imagine it. Sorry :( I guess it's time people on both sides fire their slide editors so that I (and hopefully others) can have a better view of the problem and the solutions
This has pictures:
A side-by-side visual comparison would probably be a good idea. I'm working on such a picture, I hope to send it tomorrow.
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB) Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed. Note (2): to assist those who might want to make derived works, I also made the original SVG file available. Please note that the work is licensed under CC BY-SA (refer to the file for a URL). The file may contain parts that are encoded in extensions to SVG that are specific to my editor (Inkscape); if the file doesn't work with your own editor, let me know and I'll produce a "neutral" version. http://dl.dropbox.com/u/3512486/boost_branching_model.svg (119 kB) Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2]. HTH, -Julian 1. http://lists.boost.org/Archives/boost/2012/02/190257.php 2. http://lists.boost.org/Archives/boost/2012/02/190269.php
On Fri, Feb 10, 2012 at 4:01 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Julian Gonggrijp wrote:
Mika Heiskanen wrote:
On 02/09/2012 04:10 PM, Julien Nitard wrote:
[...]
This doesn't fit in my small brain when I try to imagine it. Sorry :( I guess it's time people on both sides fire their slide editors so that I (and hopefully others) can have a better view of the problem and the solutions
This has pictures:
A side-by-side visual comparison would probably be a good idea. I'm working on such a picture, I hope to send it tomorrow.
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
Wow! Thanks a lot for your efforts!
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
Looks good, so far. I have several questions: 1) What are all the steps which are not annotated? Updates by authors which do not work on stuff in my working set? 2) What happens to that abandoned branch? Will it remain publicly visible? 3) What exactly is the purpose of the blue branch? 4) Will there be one big boost repository? Or will every library have their own sub repository?
Note (2): to assist those who might want to make derived works, I also made the original SVG file available. Please note that the work is licensed under CC BY-SA (refer to the file for a URL). The file may contain parts that are encoded in extensions to SVG that are specific to my editor (Inkscape); if the file doesn't work with your own editor, let me know and I'll produce a "neutral" version. http://dl.dropbox.com/u/3512486/boost_branching_model.svg (119 kB)
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
HTH, -Julian
1. http://lists.boost.org/Archives/boost/2012/02/190257.php 2. http://lists.boost.org/Archives/boost/2012/02/190269.php
Thanks for further clarification, Thomas
Thomas Heller wrote:
On Fri, Feb 10, 2012 at 4:01 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
[...]
Looks good, so far. I have several questions: 1) What are all the steps which are not annotated? Updates by authors which do not work on stuff in my working set?
Just some additional commits to give the figure a slightly more "realistic" look. ;-) They might or might not affect your working set, I believe the picture would work either way.
2) What happens to that abandoned branch? Will it remain publicly visible?
Since git is decentralized, it depends on who passed the branch to which repository (it would be public if somebody pushed the branch to a central repository). However, if I'm right, the abandoned branch *will* remain available in those repositories where it has been available at all (i.e. at least the repository of the author).
3) What exactly is the purpose of the blue branch?
It contains the linear history of all releases, nothing more and nothing less. One advantage of such a master branch is that you can use merges into that branch as a trigger for running scripts. For example: a script that clones the file tree to a new directory, strips unnecessary files from the copy and finally wraps it into zip, bz2 and 7z archives with the version number in the name.
4) Will there be one big boost repository? Or will every library have their own sub repository?
Actually the branching model presented here doesn't presume any specific modularization model. You can still go either way. A monolithic Boost repository should be perfectly manageable with the gitflow branching model, though.
Thanks for further clarification,
Thank you for asking these questions, it helps me to further clarify my ideas. Also, note that the gitflow side of my picture is mostly just a reproduction of the images (and some of the explanation) over here: http://nvie.com/posts/a-successful-git-branching-model/ -Julian
On 10 February 2012 15:01, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
Having thought about it a bit, it might be the case that I exaggerated the issue. It certainly matters to me, but I'm not sure about other developers. A lot of the newer libraries don't put much effort into supporting the more obscure compilers.
Daniel James wrote:
On 10 February 2012 15:01, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Good to hear that at least I didn't under-estimate it. :-) I guess the difference between a merge with manual exceptions and cherry picking is only gradual, but I strongly agree neither is ideal.
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
Having thought about it a bit, it might be the case that I exaggerated the issue. It certainly matters to me, but I'm not sure about other developers. A lot of the newer libraries don't put much effort into supporting the more obscure compilers.
Perhaps, but I think there is also another reason why the testing issue is not as severe as it may seem. I'll post about it tomorrow. -Julian
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Good to hear that at least I didn't under-estimate it. :-) I guess the difference between a merge with manual exceptions and cherry picking is only gradual, but I strongly agree neither is ideal.
Thanks for the effort, but what you proposed is a perfectly valid SVN workflow to me. There's nothing specific to git, besides the naming conventions of the branches, if I had to draw one for SVN the result would be the exact same with s/develop/trunk/ and s/master/tags/. On the other hand, whether we use git or SVN, I agree that the current model is not efficient. I think that trunk and release are redundant, it should be just trunk (this is not recommended just by me, see the wikipedia entry on continuous integration that I quoted earlier), with tags for releases. Since trunk is automatically tested, I see no reason to add an additional step before release that seemed to be completely neglected by developers. Removing that unecessary (IMHO) release branch may force people to pay more attention to what they are commiting and lower the load on the test system (which seems to be a problem) because there's no more release to test. Instead, a temporary release branch may be created from trunk and worked on directly when the beta is fixed. (And it seems to be that this is exactly what you proposed on your git schema) Julien
Julien Nitard wrote:
Thanks for the effort, but what you proposed is a perfectly valid SVN workflow to me. There's nothing specific to git, besides the naming conventions of the branches, if I had to draw one for SVN the result would be the exact same with s/develop/trunk/ and s/master/tags/.
No, there is a fundamental difference between svn and git. Let me elaborate. In svn, by "branch" we just mean a branch of the file tree in the repository. The repository as a whole has a single history which is a linear sequence of revisions. So of course you can make a feature branch, but a commit to that feature branch is really also a commit to all other branches, the trunk and all tags -- and vice versa. If at second thought you don't like your last three commits to the feature branch, you can't just revert history because that might also undo, say, the last twenty commits other people made to trunk. So you always have to manually select which files or subtrees to revert. In git on the other hand, /history/ is what branches and merges. A commit to a feature branch (your working subhistory) leaves all other branches (parallel asynchronous subhistories) unaffected. Resetting to a previous commit also leaves all other branches unaffected, so you don't have to do any manual selection. This explanation is mostly in terms of reverting changes, but there is much more at stake here. Both svn and git allow you to make a separation of concerns in the file tree, but only git allows you to make a separation of concerns in history. The git history model corresponds much better to a situation where different developers are working in parallel on different tasks at different work paces. The difference goes so deep that even the commits themselves have a different "feel". In git, the most natural thing to do is to make many small commits, each of which represents a logical unit of change; and because other authors are working on separate branches, all of those small unitary commits will stay together in history. In svn, when collaborating with many people, you have to choose between two evils: either you make many small commits which get interspersed with commits by other authors, or you collect many changes into one big commit, which makes it a big commitment indeed.
On the other hand, whether we use git or SVN, I agree that the current model is not efficient. I think that trunk and release are redundant, it should be just trunk (this is not recommended just by me, see the wikipedia entry on continuous integration that I quoted earlier), with tags for releases. Since trunk is automatically tested, I see no reason to add an additional step before release that seemed to be completely neglected by developers.
Removing that unecessary (IMHO) release branch may force people to pay more attention to what they are commiting and lower the load on the test system (which seems to be a problem) because there's no more release to test. Instead, a temporary release branch may be created from trunk and worked on directly when the beta is fixed. (And it seems to be that this is exactly what you proposed on your git schema)
Yes, basically the purpose of the gitflow develop branch /is/ to be a continuous integration branch. It's the branch of history where a project is permanently held in bleeding-edge condition (note that this would also facilitate nightly builds, for example). Large-ish changes tend to temporarily mess up the code, so they're isolated in feature branches to keep the develop branch tidy (though as I explained above, that's not the only good thing about feature branches). If "tidy" is not enough and you need to make a "serious" stable release, you fork a temporary release branch so the continuous integration on the develop branch can go on without interruption. -Julian
No, there is a fundamental difference between svn and git. Let me elaborate.
In svn, by "branch" we just mean a branch of the file tree in the repository. The repository as a whole has a single history which is a linear sequence of revisions. So of course you can make a feature branch, but a commit to that feature branch is really also a commit to all other branches, the trunk and all tags -- and vice versa.
This is just wrong. A commit (or revert) to a branch is a commit to that branch only. And don't tell me that the shared version number is a problem.
If at second thought you don't like your last three commits to the feature branch, you can't just revert history because that might also undo, say, the last twenty commits other people made to trunk. So you always have to manually select which files or subtrees to revert.
You're wrong, again. This is completely possible and even simple. I only have to select (including cherry picking) the commits I want to revert. The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not. Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible. Julien
Julien Nitard wrote:
No, there is a fundamental difference between svn and git. Let me elaborate.
In svn, by "branch" we just mean a branch of the file tree in the repository. The repository as a whole has a single history which is a linear sequence of revisions. So of course you can make a feature branch, but a commit to that feature branch is really also a commit to all other branches, the trunk and all tags -- and vice versa.
This is just wrong. A commit (or revert) to a branch is a commit to that branch only. And don't tell me that the shared version number is a problem.
Of course I may be wrong. Please help me to clarify: if I checkout branch A (only) and commit a change to it and branch B is not affected along the way, is that because (1) I didn't edit branch B, so naturally it wouldn't be affected, or (2) svn somehow treats edits on branch A as events that are isolated from edits on branch B? The latter would mean that svn could, for example, prevent me from doing the following: checkout the entire /branches directory, make edits on both /branches/A and /brances/B, then commit all changes together in one revision.
If at second thought you don't like your last three commits to the feature branch, you can't just revert history because that might also undo, say, the last twenty commits other people made to trunk. So you always have to manually select which files or subtrees to revert.
You're wrong, again. This is completely possible and even simple. I only have to select (including cherry picking) the commits I want to revert.
So if I checkout branch A (only) and I say "svn revert 2", only the files in branch A will be affected because svn understands that I'm not working on other branches. Is that what you're saying? Yes, basically that means I'm wrong. However I want to ask you how svn is doing this. Personally I think history stays as it is -- say at revision 3 -- but that svn replaces the files in my working directory with those from branch A at revision 2. Next I can edit those files or commit them straight away, which would produce revision 4. A reset in git is different: you undo history rather than retrieving files from an old commit. I'm still inclined to think that if there was such a thing as undoing history in svn, it would always affect the entire repository rather than just your working branch. Note that if I'm right (but again, I might not), git also has a revert operation, which lets you retrieve files from an old commit without affecting history. One final note: if I run "svn help revert", it does seem to need a path as an argument, and it also says it isn't able to restore deleted directories. To me, that seems strictly less powerful than a git reset.
The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not.
Please take my word that I didn't intend to give misinformation. I made an error because I went a little too quickly over the issue and failed to realise that a reset in git is a different beast from a revert in svn. I might have made other errors as well, which would also be unintentional, but that's still open to discussion for as far as I'm concerned.
Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible.
It's ok, nothing personal, I like a cordial tone too. -Julian
Hi,
The latter would mean that svn could, for example, prevent me from doing the following: checkout the entire /branches directory, make edits on both /branches/A and /brances/B, then commit all changes together in one revision.
Form the users point of view an svn branch is simply a copy of the trunk. I guess that should answer all of your questions. Christof -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
AMDG On 02/11/2012 08:04 AM, Julian Gonggrijp wrote:
Julien Nitard wrote:
No, there is a fundamental difference between svn and git. Let me elaborate.
In svn, by "branch" we just mean a branch of the file tree in the repository. The repository as a whole has a single history which is a linear sequence of revisions. So of course you can make a feature branch, but a commit to that feature branch is really also a commit to all other branches, the trunk and all tags -- and vice versa.
This is just wrong. A commit (or revert) to a branch is a commit to that branch only. And don't tell me that the shared version number is a problem.
Of course I may be wrong. Please help me to clarify: if I checkout branch A (only) and commit a change to it and branch B is not affected along the way, is that because (1) I didn't edit branch B, so naturally it wouldn't be affected, or (2) svn somehow treats edits on branch A as events that are isolated from edits on branch B?
(1). The thing is, in svn, we can operate on any subtree, and ignore the rest of the repository. So, for example, given the following situation: revision 1: branch A revision 2: branch B revision 3: branch A revision 4: branch B If we want to undo the most recent change to branch A, the command is svn merge -r HEAD:2 branches/A Revision 4 doesn't affect branch A, so it's left alone.
The latter would mean that svn could, for example, prevent me from doing the following: checkout the entire /branches directory, make edits on both /branches/A and /brances/B, then commit all changes together in one revision.
svn allows this, although I've never seen anyone actually do it. In Christ, Steven Watanabe
Steven Watanabe wrote:
(1). The thing is, in svn, we can operate on any subtree, and ignore the rest of the repository. So, for example, given the following situation:
revision 1: branch A revision 2: branch B revision 3: branch A revision 4: branch B
If we want to undo the most recent change to branch A, the command is
svn merge -r HEAD:2 branches/A
Revision 4 doesn't affect branch A, so it's left alone.
isn't this scenario a somewhat basic feature of a version control system ? doesn't every SCM support that ? Steven Watanabe wrote:
The latter would mean that svn could, for example, prevent me from doing the following: checkout the entire /branches directory, make edits on both /branches/A and /brances/B, then commit all changes together in one revision.
svn allows this, although I've never seen anyone actually do it.
yeah, and I think a developer who does something like that is really giving the integrator a hard time. merging two branches back to the trunk is essentially merging three development lines at the same time and i can think of no reason why this should be necessary.
[...]
isn't this scenario a somewhat basic feature of a version control system ? doesn't every SCM support that ?
Yes it is, but there were some misunderstandings that needed clarification.
the designers of svn would have done well to declare the repo history as immutable - what goes in stays in. if you need to change it, commit a new revision. don't alter history, don't modify the past. [...]
i had a developer run a script that was supposed to 'fix a few things' in the repo history. seemed to work ok on his test repo, but truncated commit messages in the production repo and shifted them by a few commits. this effectively rendered the repo useless.
Now I guess you've heard of backups, that's what they re supposed to protect from. Note that hooks are an entirely optional feature managed by the admin, not the developers.
the canonical way how this is handled in git is to submit a new revision that fixes the mistakes in the past. you can modify the history in git, but this will hickup once you push them upstream, so you will do this only once: http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
This is a fair point in favor of git, but I am not sure this is a compelling reason to switch by itself. Julien
On Sun, Feb 12, 2012 at 04:14:26PM +0900, Julien Nitard wrote:
i had a developer run a script that was supposed to 'fix a few things' in the repo history. seemed to work ok on his test repo, but truncated commit messages in the production repo and shifted them by a few commits. this effectively rendered the repo useless.
Now I guess you've heard of backups, that's what they re supposed to protect from. Note that hooks are an entirely optional feature managed by the admin, not the developers.
Such damage may not be immediately noticeable and if it takes weeks/months/years to notice, reverting is not as easy as restoring from backups. In any way, if you need to perform history cleanup or other tasks as part of a migration or just sanitation of an existing repo, I would recommend taking a look at ESR's tool 'reposurgeon' [1]. [1] http://www.catb.org/esr/reposurgeon/ -- Lars Viklund | zao@acc.umu.se
AMDG On 02/11/2012 08:04 AM, Julian Gonggrijp wrote:
So if I checkout branch A (only) and I say "svn revert 2", only the files in branch A will be affected because svn understands that I'm not working on other branches. Is that what you're saying?
Right, although svn revert is the wrong tool. svn revert undoes uncommitted changes to the working copy.
Yes, basically that means I'm wrong. However I want to ask you how svn is doing this. Personally I think history stays as it is -- say at revision 3 -- but that svn replaces the files in my working directory with those from branch A at revision 2. Next I can edit those files or commit them straight away, which would produce revision 4.
Yep.
A reset in git is different: you undo history rather than retrieving files from an old commit. I'm still inclined to think that if there was such a thing as undoing history in svn, it would always affect the entire repository rather than just your working branch. Note that if I'm right (but again, I might not), git also has a revert operation, which lets you retrieve files from an old commit without affecting history.
That's true, which is why svn doesn't allow history to be changed at all. (Of course, it you have physical access to the repository you can delete the most recent revisions) In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
On 02/11/2012 08:04 AM, Julian Gonggrijp wrote:
So if I checkout branch A (only) and I say "svn revert 2", only the files in branch A will be affected because svn understands that I'm not working on other branches. Is that what you're saying?
Right, although svn revert is the wrong tool. svn revert undoes uncommitted changes to the working copy.
[...] Personally I think history stays as it is -- say at revision 3 -- but that svn replaces the files in my working directory with those from branch A at revision 2. Next I can edit those files or commit them straight away, which would produce revision 4.
Yep.
[...] I'm still inclined to think that if there was such a thing as undoing history in svn, it would always affect the entire repository rather than just your working branch. [...]
That's true, which is why svn doesn't allow history to be changed at all. (Of course, it you have physical access to the repository you can delete the most recent revisions)
Thanks for all of your clarifications, also in your other response. (For those who wonder what they mean for the discussion between me and Julien Nitard: I was right that there is a fundamental difference between svn and git with regard to branching, while Julien was right that much of the gitflow branching model can be simulated in svn. I won't press the matter any more for now.) -Julian
Steven Watanabe wrote:
That's true, which is why svn doesn't allow history to be changed at all. (Of course, it you have physical access to the repository you can delete the most recent revisions)
unfortunately, that's not true: http://subversion.apache.org/faq.html#change-log-msg the designers of svn would have done well to declare the repo history as immutable - what goes in stays in. if you need to change it, commit a new revision. don't alter history, don't modify the past. if you have ever been the admin in a commercial svn repo, you may have seen how getting pressured by management into creating a pre-revprop-change repo hook (so developers can change some typo in a commit message) opens the door to more problems than running a flux capacitor with a buggy firmware. i had a developer run a script that was supposed to 'fix a few things' in the repo history. seemed to work ok on his test repo, but truncated commit messages in the production repo and shifted them by a few commits. this effectively rendered the repo useless. the canonical way how this is handled in git is to submit a new revision that fixes the mistakes in the past. you can modify the history in git, but this will hickup once you push them upstream, so you will do this only once: http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html # ssc
On Sat, Feb 11, 2012 at 3:38 PM, Julien Nitard <julien.nitard@m4tp.org> wrote:
The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not.
Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible.
Let's discuss a concrete case. Someone without write access to the SVN repo wants to contribute somde code. 1. Checkout 2. Edit code 3. Can't commit, so can't do any kind of local checkpoints 4. Can't push, so has to generate a patch 5. Upload patch to Trac (slow, requires browser, no tool support) Someone else wants to check out this patch 6. Download patch from Trac (slow, requires browser, no tool support) 7. Apply patch DVCS would allow local commits (with commit messages), handy for larger patches DVCS would support publishing and retrieving these patches To me, these are clear and useful advantages. Greetings, Olaf
On 2/11/2012 10:46 AM, Olaf van der Spek wrote:
On Sat, Feb 11, 2012 at 3:38 PM, Julien Nitard<julien.nitard@m4tp.org> wrote:
The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not.
Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible.
Let's discuss a concrete case. Someone without write access to the SVN repo wants to contribute somde code. 1. Checkout 2. Edit code 3. Can't commit, so can't do any kind of local checkpoints 4. Can't push, so has to generate a patch 5. Upload patch to Trac (slow, requires browser, no tool support)
But Trac is globally available across all platforms without having to install anything. As is a wide variety of patch application tools.
Someone else wants to check out this patch 6. Download patch from Trac (slow, requires browser, no tool support) 7. Apply patch
DVCS would allow local commits (with commit messages), handy for larger patches DVCS would support publishing and retrieving these patches
What happens when the repo you "publish" the patch from goes away before anyone has a chance t get it? I.e. how is it different from uploading to a central server like Trac?
To me, these are clear and useful advantages.
But if that's the only advantage.. Does it seem worth it to incur the very high cost of switching a central tool? And, yes, I've asked the same question (in different words) in just about all the previous svn vs. <insert-you-tool-here> threads. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Sat, Feb 11, 2012 at 9:21 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
But Trac is globally available across all platforms without having to install anything. As is a wide variety of patch application tools.
What's your point? Assuming the DVCS tools are installed, they'd not require any additional installation either.
Someone else wants to check out this patch 6. Download patch from Trac (slow, requires browser, no tool support) 7. Apply patch
DVCS would allow local commits (with commit messages), handy for larger patches DVCS would support publishing and retrieving these patches
What happens when the repo you "publish" the patch from goes away before anyone has a chance t get it?
You mean what happens if you delete your patch/repo? Well, surprise, it's gone. :p
I.e. how is it different from uploading to a central server like Trac?
Didn't I outline the differences above?
To me, these are clear and useful advantages.
But if that's the only advantage..
It's not, it was just an example of an advantage.
Does it seem worth it to incur the very high cost of switching a central tool? And, yes, I've asked the same question (in different words) in just about all the previous svn vs. <insert-you-tool-here> threads.
-- Olaf
Olaf van der Spek wrote:
What happens when the repo you "publish" the patch from goes away before anyone has a chance t get it?
You mean what happens if you delete your patch/repo? Well, surprise, it's gone. :p
In the example of github.com, there's a big red frame around the 'delete repository' admin section marked 'DANGER ZONE'. It's kinda hard to not see that and delete a repo accidentally. There's also usually no reason to do that intentionally as you can always re-sync and re-use the repo for new development after your first changes were accepted upstream. another advantage: svn puts a '.svn' folder in every single project subfolder - and this '.svn' keeps getting in my way all the time. If you want to get rid of subversion in your local copy, you have to walk through all the subfolders and delete the '.svn' folder everywere. under git, you delete one single '.git' folder in the root folder, done.
Hi, On 12/02/2012 01:26, Steven Samuel Cole wrote:
(...)
another advantage: svn puts a '.svn' folder in every single project subfolder - and this '.svn' keeps getting in my way all the time. If you want to get rid of subversion in your local copy, you have to walk through all the subfolders and delete the '.svn' folder everywere.
under git, you delete one single '.git' folder in the root folder, done.
Just for the record since svn 1.7 there is now only one .svn folder in the root folder too. Mathieu
Mathieu Champlon wrote:
Just for the record since svn 1.7 there is now only one .svn folder in the root folder too.
oh great they improved that! i can't remember how many times those folders got in my way in some way or other. i did double-check in my local boost code tree before sending that email, but my svn client is version 1.6.17 (r1128011), so the folders are all still there. thanks for letting me know! :-)
Rene Rivera wrote:
5. Upload patch to Trac (slow, requires browser, no tool support)
But Trac is globally available across all platforms without having to install anything. As is a wide variety of patch application tools.
no matter if svn or git - if you want to do any serious work on a repo, you need a locally installed client, don't you ?
7. Apply patch
What happens when the repo you "publish" the patch from goes away before anyone has a chance t get it?
it won't. the new source code is sitting safe and sound in the contributor's personal online repository, including its entire development history. there is only one scenario in which the new source code is unavailable: a total internet outage. when was the last time this happened ? anyway, IF this happens - or simply, if you're offline: --> under subversion, you're disconnected from the repo, so any version-controlled development comes to a grinding halt. If you want to keep your changes separate, you're back to creating local copies on your harddrive just like back in the 80s before source control was invented. --> under git, development merrily goes on like nothing happened: check out, change, diff, commit, revert, etc. with full access to the revision history - the only thing you can not do when you're disconnected from your repo's origin is push changes back upstream: That will have to wait until you're back online. If you want to work on something else in the meantime and would rather not want to mix your changes, create a branch.
I.e. how is it different from uploading to a central server like Trac?
In addition to what I said above: Under Subversion, it is correct to speak about a 'patch': When new source code is 'delivered', all the receiving end sees is one set of files in the state are when they are 'published' - and the receiver needs to pull it out of trac, so there are several gaps in the tool chain. Under git, the receiver sees an entire repo with the new changes, can look through the history of the new development and for example get a feel for how often this contributor commits changes, how well they are described, how many files are changed per commit, etc. Also, there is no tool chain gap, all of this happens within one repo - and on top of that, git is aware of development history that 2 branches have in common, so the receiver does not have figure that out for himself. As a side effect, this also means that git work can be done in an SSH session, whereas in the scenario, trac is required to publish changes and that requires a browser which in turn needs a desktop environment.
But if that's the only advantage.. Does it seem worth it to incur the very high cost of switching a central tool? And, yes, I've asked the same question (in different words) in just about all the previous svn vs. <insert-you-tool-here> threads.
I have worked with Subversion in commercial projects bottom to top for 5+ years, including set up, administration, dev use, desaster recovery. After working with git, I have come to the conclusion that upgrading from svn to git is worth any effort any time. In my opinion, boost development is currently slowed down by Subversion - and as I said in the OP, this especially concerns welcoming new contributors into the project and integrating their contributions in a clearly defined and controlled manner.
Rene Rivera wrote:
But if that's the only advantage.
Next advantages: user interface. and network latency. and color. I happen to come across this just now, that's why I mention it: Situation is I want to figure out what has been going on in the boost trunk recently. I am working in the shell. host:boost-trunk user$ svn log --> takes about 10s before anything happens at all (I timed it). --> every single commit to the repo flies past me in the terminal admittedly, the boost trunk has a long history and there are many commits; as they need to be fetched over the network, this takes a little. (as mentioned, if you're offline, getting the log isn't possible at all.) ok, so don't give me all the history, just show me what happened recently, let's say last 10 commits or since first of february. host:boost-trunk user$ svn help log --> -r parameter plus something '{' DATE '}'. oh yeah, i remember now, i'd figured out some time ago how to specify an svn revision range by date. took me a little back then, so i wrote it down in some file for next time i need it. where is that file now ? no idea. let's try: host:boost-trunk user$ svn log -r { 20120212 } svn: Syntax error in revision argument '{' host:boost-trunk user$ svn log -r '{ 20120212 }' svn: Syntax error in revision argument '{ 20120212 }' host:boost-trunk user$ svn log -r '{20120212}' --> wait 10 seconds ------------------------------------------------------------------------ r76973 | danieljames | 2012-02-11 23:34:30 +1100 (Sat, 11 Feb 2012) | 1 line Iostreams: Fix test for latest Boost.Test changes. ------------------------------------------------------------------------ host:boost-trunk user$ svn log -r '{20120201}' --> WAIT 10 SECONDS ------------------------------------------------------------------------ hmm, so that's the changes on that date. seems like i have to specify two dates to get the revisions i want to see. ok, never mind. i could probably google it, but why does the svn online help not tell me what to do straight away ? hmmm. so revision by date range isn't immediately obvious. how about 'last 10 revisions' ? host:boost-trunk user$ svn help log --> yeah, thanks but no thanks. at this stage, I could probably compensate svn's failure to provide a proper user interface by piping all output from svn log into less or so. i could google it. but why do i have to ? HOW DOES THIS WORK UNDER GIT ? hmmm, no idea how to get git history, maybe just try this: host:some_branch user$ git log --> zero delay. ZERO. git responds quicker than I can type the command. --> displays commits in 'less' style, i.e. fills one screen, then stops with : waits for q to quit, space for next screen, enter for next line. --> works this way no matter how big the repo is, no matter if offline. job done. every time you hit space, you go back in revision history one screen at a time. just for the sake of it: how to limit revision range ? host:some_branch user$ git help log ... OPTIONS -<n> Limits the number of commits to show. ... ... host:some_branch user$ git log -5 --> displays last 5 revisions. done. took 5 seconds to figure out. while we're at it: some of the changes I've done recently are in really long lines; this makes it hard to spot the actual difference, see e.g. https://svn.boost.org/trac/boost/attachment/ticket/6541/20120210_fixed_typos... host:boost-trunk user$ svn status --> wait another 10 seconds ... M tools/build/v2/user-config.jam host:boost-trunk user$ svn diff --color tools/build/v2/user-config.jam svn: invalid option: --color Type 'svn help' for usage. host:some_branch user$ git status --> ZERO DELAY ... # modified: main.cpp ... host:some_branch user$ git diff -color main.cpp --> works in full color in the terminal you can now choose to make a snide remark along the lines of 'yeah, you have to know how to use your tools' or so. i say this is the 21st century and if i need longer than a couple of seconds to figure out how to use a tool, then the tool is not good enough. fact is: 1. svn has a clumsy, non-intuitive user interface. q.e.d. 2. svn makes me wait with every command that requires the network. 3. svn fails to provide features i need every day work. git fixes all that. # ssc
hmmm. so revision by date range isn't immediately obvious. how about 'last 10 revisions' ?
host:boost-trunk user$ svn help log --> yeah, thanks but no thanks.
For the record, it's "svn log --limit 10". This option is described in "svn help log", and I don't see anything about its position or description that would make it harder to find than the corresponding option in "git help log"... Regards, Nate
Nathan Ridge wrote:
For the record, it's "svn log --limit 10". This option is described in "svn help log", and I don't see anything about its position or description that would make it harder to find than the corresponding option in "git help log"...
thanks for pointing that out. agreed, i stand corrected. guess after waiting and waiting and not being able to get revisions by date range quickly, i did not have the patience anymore to look at the help screen properly.
Hi,
The level of wrongness in this email (at least the quoted part above) is such that it is hard for me to keep calm. I am, admittedly, biased toward SVN. I can accept that DCVS systems like git may improve the workflow on projects like boost, but you're twisting facts. I am currently wondering whether you did that on purpose or not.
Sorry if this was too strong, I am not perfect myself and make mistakes too. I would like to keep the discussion in a cordial tone if possible.
Let's discuss a concrete case. Someone without write access to the SVN repo wants to contribute somde code. 1. Checkout 2. Edit code 3. Can't commit, so can't do any kind of local checkpoints 4. Can't push, so has to generate a patch 5. Upload patch to Trac (slow, requires browser, no tool support)
But Trac is globally available across all platforms without having to install anything. As is a wide variety of patch application tools.
You will need to install an svn client when you want to use svn. Trac is not a VCS and the upload of patches as attachment to Trac tickets for me is a missuse of tickets. Anyway, of course you can also create patch files with git, upload them to trac and apply them somewhere else. The various commits will be available in the resulting branch as well, so the result is identical to using git pull.
I.e. how is it different from uploading to a central server like Trac?
1. git push/pull is usually a lot faster. 2. you can still upload patches to Trac, if you really like it so much. 3. instead you can also create tickets with pull requests from servicxes like e.g. github or your own webserver. 4. someone, who is not the maintainer might like your patch better than him. He can apply it to his repository without disturbing anybody else. He can rebase it on any other changesets the maintainer puts into his repository. 5. after you submitted your patch you can go on working on the same repository without having to waint until your patch is applied to a branch in the main repository and you can svn update. 6. The maintainer can experiment with your patch. E.g. he might like it mostly, but fix a small part, before he pushes it into the main repository. Then the fix is in the version history with his name, while your changes are in the history with your name. It simply opens a huge ammount of more options. Christof -- okunah gmbh Software nach Maß Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
On 02/10/2012 04:31 PM, Daniel James wrote:
On 10 February 2012 15:01, Julian Gonggrijp<j.gonggrijp@gmail.com> wrote:
Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
Having thought about it a bit, it might be the case that I exaggerated the issue. It certainly matters to me, but I'm not sure about other developers. A lot of the newer libraries don't put much effort into supporting the more obscure compilers.
Well, i still like to believe that one of boost's strengths is the large platform support. This is also the reason why I believe that a branching model is not a good solution for boost. Here is why: When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it. After a couple of days the test cycled, and i see on which platforms these tests fail and i try to fix it. This is where I have problems with this whole branching model, when will my features i pushed to a branch be tested? I actually believe that despite the possible ease of development and contribution such a model actually leads to a unstable main branch or trunk. I think testing should be a concern, and i would rather like to see a discussion about test improvements than VCS. However, if a different VCS means easier testing (for the test runners), I am all for it. I am curios to hear more about that! Regards, Thomas
On Fri, Feb 10, 2012 at 11:25 AM, Thomas Heller <thom.heller@googlemail.com>wrote:
Well, i still like to believe that one of boost's strengths is the large platform support. This is also the reason why I believe that a branching model is not a good solution for boost. Here is why:
When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it. After a couple of days the test cycled, and i see on which platforms these tests fail and i try to fix it. This is where I have problems with this whole branching model, when will my features i pushed to a branch be tested? I actually believe that despite the possible ease of development and contribution such a model actually leads to a unstable main branch or trunk. I think testing should be a concern, and i would rather like to see a discussion about test improvements than VCS. However, if a different VCS means easier testing (for the test runners), I am all for it. I am curios to hear more about that!
Well that reminds me of a post expressing a similar thought about branching models vs. testing < http://altdevblogaday.com/2012/02/09/branching-strategy-is-not-a-remedy-for-instability/>. What I take from it in the context of Boost.. Is that Boost is stable because we have a rather simple and testing-centric non-branching model. Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Fri Feb 10 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On Fri, Feb 10, 2012 at 11:25 AM, Thomas Heller <thom.heller@googlemail.com>wrote:
Well, i still like to believe that one of boost's strengths is the large platform support. This is also the reason why I believe that a branching model is not a good solution for boost. Here is why:
When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it. After a couple of days the test cycled, and i see on which platforms these tests fail and i try to fix it. This is where I have problems with this whole branching model, when will my features i pushed to a branch be tested? I actually believe that despite the possible ease of development and contribution such a model actually leads to a unstable main branch or trunk. I think testing should be a concern, and i would rather like to see a discussion about test improvements than VCS. However, if a different VCS means easier testing (for the test runners), I am all for it. I am curios to hear more about that!
Well that reminds me of a post expressing a similar thought about branching models vs. testing < http://altdevblogaday.com/2012/02/09/branching-strategy-is-not-a-remedy-for-instability/>. What I take from it in the context of Boost.. Is that Boost is stable because we have a rather simple and testing-centric non-branching model.
Another interpretation: Boost is stable because working on it has become unwieldly, and projects don't change as often as they should :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Thomas Heller wrote:
On 02/10/2012 04:31 PM, Daniel James wrote:
On 10 February 2012 15:01, Julian Gonggrijp<j.gonggrijp@gmail.com> wrote:
Note (3): while this image helps to explain my point in [1], it turns out from [2] that I didn't actually address Daniel James' point. I'll return to the testing issue in a new reply to [2].
Having thought about it a bit, it might be the case that I exaggerated the issue. It certainly matters to me, but I'm not sure about other developers. A lot of the newer libraries don't put much effort into supporting the more obscure compilers.
Well, i still like to believe that one of boost's strengths is the large platform support.
++
This is also the reason why I believe that a branching model is not a good solution for boost. Here is why:
When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it.
Do you realise that what you describe here is basically to make a feature branch locally on your computer (but without history), then when you feel ready for the polishing stage merge it back into the trunk? It's exactly the process I described in my latest reply to Daniel James. You're already doing exactly what you'll do with the gitflow branching model, but without two of its advantages: lightweight commits (as described in my latest reply to Julien Nitard) and a history of your changes prior to the merge into trunk.
After a couple of days the test cycled, and i see on which platforms these tests fail and i try to fix it. This is where I have problems with this whole branching model, when will my features i pushed to a branch be tested?
Answer: when you merge your implemented changes into the develop branch, they're automatically staged for the next testing cycle. Just like the current situation.
I actually believe that despite the possible ease of development and contribution such a model actually leads to a unstable main branch or trunk.
I believe you need not to worry about this.
I think testing should be a concern, and i would rather like to see a discussion about test improvements than VCS. However, if a different VCS means easier testing (for the test runners), I am all for it. I am curios to hear more about that!
I completely agree that testing is very important, and I also think that testing as an issue is mostly orthogonal to the branching model and the VCS. For as far as I can see git won't change much about the testing procedure, except that the volunteers might have less work to do on average (as observed by Julien). IMO if the current testing model needs revision, it should get its own thread. HTH, -Julian
On 11 February 2012 14:10, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Thomas Heller wrote:
This is also the reason why I believe that a branching model is not a good solution for boost. Here is why:
When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it.
Do you realise that what you describe here is basically to make a feature branch locally on your computer (but without history), then when you feel ready for the polishing stage merge it back into the trunk? It's exactly the process I described in my latest reply to Daniel James.
I don't think you realise quite how long the 'polishing stage' can take, it can be months. That's why I was trying to describe a system where things can be tested without merging to the development branch.
Daniel James wrote:
On 11 February 2012 14:10, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Thomas Heller wrote:
This is also the reason why I believe that a branching model is not a good solution for boost. Here is why:
When i develop a new feature i do that on trunk, whenever i feel confident that the feature works as i expected it, i commit it.
Do you realise that what you describe here is basically to make a feature branch locally on your computer (but without history), then when you feel ready for the polishing stage merge it back into the trunk? It's exactly the process I described in my latest reply to Daniel James.
I don't think you realise quite how long the 'polishing stage' can take, it can be months. That's why I was trying to describe a system where things can be tested without merging to the development branch.
Thanks for pointing this out. I now realize that you and Thomas have expressed similar ideas about a better testing model. I was about to start a new thread on that topic; your post came just in time to help me improve my post. I propose to continue this discussion in the new testing model thread, because I think the matter has enough substance to treat it as an autonomous topic. -Julian
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Julian Gonggrijp Sent: Friday, February 10, 2012 3:02 PM To: boost@lists.boost.org Subject: Re: [boost] [git] neglected aspects
Julian Gonggrijp wrote:
A side-by-side visual comparison would probably be a good idea. I'm working on such a picture, I hope to send it tomorrow.
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
Thanks for all of this - I am beginning to understand how git might help us. Can I also raise the potential (re-)position of boost-sandbox? At present, some links in jamfiles, and especially many in docs, need tiresome readjustment to be able to move from sandbox to trunk. Would it be possible to avoid this by making sandbox a branch from trunk. Most of the items of course never make it into trunk, and are abandoned, but if they do get accepted, then moving will be painless. Could using git help us here? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
Julian Gonggrijp wrote:
A side-by-side visual comparison would probably be a good idea. I'm working on such a picture, I hope to send it tomorrow.
As promised: http://dl.dropbox.com/u/3512486/boost_branching_model.pdf (82 kB)
Thanks for all of this - I am beginning to understand how git might help us.
Can I also raise the potential (re-)position of boost-sandbox?
At present, some links in jamfiles, and especially many in docs, need tiresome readjustment to be able to move from sandbox to trunk.
Would it be possible to avoid this by making sandbox a branch from trunk.
Most of the items of course never make it into trunk, and are abandoned, but if they do get accepted, then moving will be painless.
Could using git help us here?
Yes, git can certainly help here, because of its decentralized nature. If I'm right the sandbox is mostly used for new libraries that authors intend to add to the main distribution at some point of time. With git, those authors can just clone the central boost repository and add their library to the clone (in a feature branch). They can also publish their clone in order to collaborate. When the additions in the clone are ready to be pushed/pulled into the central boost repository, you can just do that and no file paths will need to be changed. After that you can merge the new feature branch into develop. The merge shouldn't require any manual intervention either, as long as the collaborators on the clone didn't touch any other parts of the boost tree along the way. For those cases where the sandbox is used for additions to existing libraries, or where the author already has write access to the central repository, the sandbox can simply be omitted by using feature branches instead -- without any need to clone the central repository. If this needs a picture as well, I'll be happy to make it (tomorrow). HTH, -Julian
This has pictures:
Just to throw in another perspective: when switching from svn to git in our project [1], we used this model as a starting point - with a few modifications. Here is an overview of what we came up with: http://www.bro-ids.org/development/process.html We initially used both a master and a devel branch, but then noticed that the devel branch does not really get used. Instead, developers preferred the topic branch concept. Our master is essentially the development branch in which nightly testing occurs. Matthias [1] http://www.bro-ids.org
participants (17)
-
Christof Donat -
Daniel James -
Dave Abrahams -
David A. Greene -
Julian Gonggrijp -
Julien Nitard -
Lars Viklund -
Mathieu Champlon -
Matthias Vallentin -
Mika Heiskanen -
Nathan Ridge -
Olaf van der Spek -
Paul A. Bristow -
Rene Rivera -
Steven Samuel Cole -
Steven Watanabe -
Thomas Heller