The difficulty here is that your parent is trying to maintain 2 histories locally at the same time, which is of course a PITA because git was designed for such a nonsensical usage case. The solution is to automate handling the second history.
For instance, one could just create the 2008 version of the history by rewriting the 2010 history before pushing, which could be achieved with git's `filter-branch' command.
Alternatively, one could implement commit hooks or other scripts that simultaneously create commit objects and manage a second branch by hand using the low-level plumbing tools to actually commit the `solution' and `project' files from some particular revision with the 2008 files (perhaps a commit tagged `v2008' or something). Of course, one has to keep in mind that these will in fact be 2 separate histories, so merge conflicts might crop up between the `solution' and `project' files over time.
what if you only want to push/commit parts of the change you made in a given file then ?
You shouldn't conflate committing and pushing.
For committing parts of the change you made in a given file, use `git add -p' to sift through the diff hunks and even edit hunks; `git stash' can also be useful here.
All assets are in RCS as there are many code changes tied to art assets, they need to be in sync.
Perhaps git's submodule feature would be of service here. From the man page: 'Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.'
The last shipped game that I worked on had a minimum sync size of ~43GB. That did not include movies, design documents, style guides or multiple language support. That built the PC, XBox360 and PS3 SKUs. A full sync was well over 100GB which I never did as I didn't need that stuff.
I wonder whether something like bup (which is based on git) might be useful for managing the large datasets; given that bup stores data in git repos, you could probably even use it as the basis for a submodule (perhaps with the help of scripts to unload the data where desired).
However, I think the main point is that git is optimized for managing code history and that it's kind of silly to expect git or any other tool to handle both usage cases well. When it comes to managing code history alone, git probably provides better tools than what you espouse:
I want my multiple change lists and the ability to sync any file to any revision easily for testing. I want to be able to select someone else's change list and revert it locally without hassle. I just find that git gets in my way when I have shit to do and little time to do it.
You can do all of these things easily with git's `fetch', `log', `whatchanged', `diff', `merge', `show', `checkout', `reset', `stash', `revert', `rebase', etc.
If there's on thing you can do with git, it's slice and dice code and revision history in any which way you please. Frankly, I think you're frustrated because you don't know what you're talking about with regard to git; you've never bothered to learn what you assume is an inferior tool. In reality, the inferiority is your mindset.
What does 'physical thing' even mean? People are always talking about software as though it's intangible and metaphysical. This is because most people don't understand what's going on; they can't see gears and levers and wheels that can be turned by hand, so they assume that some kind of magic is at work.
There is no fundamental difference between the Newcomen steam engine and Linux's latest execution scheduler.
Everything in this Universe is describable with Mathematics/Logic; everything is just information.
Either patents apply to everything or they apply to nothing.
In most cases, it's not copying that is at issue, but rather compensation for the arduous task of finding the original, and I think therein lies the solution: Should the inventor of rounded GUI elements be compensated in the same ways as the inventor of the LCD screen? The contemporary patent problem has to do with preposterously disproportionate entitlement.
Well, you've brought the discussion full circle: What you don't seem to grasp is that standardization is not about innovation; it's about recognizing long-existing commonality and what has been proven to work or be useful, which is exactly what POSIX does and which is exactly why POSIX leaves some behavior as implementation-defined or even undefined.
The C++0x standard is another good example of standardization done properly; rather than innovate FROM THE STANDARD, it largely just recognizes widely used stuff that has been around IN PRACTICE for a long time (boost libraries, constructs from other languages, usage patterns, design patterns, etc.).
In any case, I see you've declined to justify your example.
My point was simply that you cannot rely on undefined or implementation-defined behavior across implementations. Moreover, part of the purpose of a standard is to provide a centralized delineation of exactly what is defined behavior, what is implementation-defined behavior (including the set of possible implementation choices), and what is undefined behavior; this is far preferable to only having a collection of a myriad of proprietary documentation (most of which is often incomplete).
Now, help me understand your scenario.
Try this on solaris and then try it on hp-ux:
shm_open("/shm-test", O_RDWR, 0600);
It will work on solaris and fail on hp-ux because the underlying mechanism for tracking the shm namespace is undefined by posix, so different vendors have implemented it in "innovative" ways. Posix is riddled with shit like that.
The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.
Written by someone who has never tried to deploy POSIX standard code on multiple vendor systems.
Written by someone who still doesn't understand the POSIX standard; if a system is POSIX compliant, then you know all of the possible behaviors, because they are listed in the POSIX standard. That's the point.
The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.
Perhaps Fedora but not Suse is running an NTP (Network Time Protocol) client, and perhaps Suse is configured for the wrong time zone or the hardware clock and Suse's configuration don't agree on whether time is stored as local time or as time at UTC offset +0000.
I believe that Google+ allows users to back up all of their data (pictures, posts, whatever), including Google+-specific data like whose in which 'circles'. Can someone correct me?
there is currently a legal and practical difference beween on the one hand matter & possessions and on the other information and virtual things.
What does 'virtual thing' even mean? People are always talking about software as though it's intangible and metaphysical. This is because most people don't understand what's going on; they can't see gears and levers and wheels that can be turned by hand, so they assume that some kind of magic is at work.
There is no fundamental difference between the Newcomen steam engine and Linux's latest execution scheduler.
There is no "freedom of possession" which entitles you to have any object you want to have.
The only thing that gives you the "right of possession" is physical violence. The only reason there is the concept of "right of possession" in the first place is the fact that there are limited resources, which simply means that some information is more easily copied than other information.
In most cases, it's not copying that is at issue, but rather compensation for the arduous task of finding the original, and I think therein lies the solution: Should the inventor of rounded GUI elements be compensated in the same ways as the inventor of the LCD screen? The contemporary patent problem has to do with preposterously disproportionate entitlement.
While a bitcoin's properties make it seem like a big improvement over conventional currency, the fiat nature of its value cripples it in the same fundamental way; I hope that we figure out how to couple the value of currency with the fundamental laws/constants that define this Universe so that it becomes impossible to abandon it as a measurement of work.
I'm not sure that really counts as an explanation because there are really excellent films that have ensemble casts rather than a well-defined protagonist. Alien comes to mind.
My comment was only meant as a pointer in the right direction: There are tools which are very helpful.
Moreover, there are various week-numbering standards, each of which defines the first and last weeks of the year differently, making this a more difficult problem when there is no specification.
However, let's assume you want ISO 8601's definition of week 33. Then, the first week of the year is defined as the week with the year's first Thursday, and the first day of every week is Monday. So, let's start with 2011-January-01, or, more succinctly:
$ date --utc -d 'jan 1' Sat Jan 1 00:00:00 UTC 2011
Of course, that output format depends on the current locale, so a more definitive version would be:
$ date -d 'jan 1' +%A Saturday
So, the first day of week 01 in 2011 is:
$ date --utc -d 'jan 1 2 days' Mon Jan 3 00:00:00 UTC 2011
Thus, the start of week 33 (which is the start of week 01 plus 32 more weeks) would be:
$ date --utc -d 'jan 1 2 days 32 weeks' Mon Aug 15 00:00:00 UTC 2011
Interestingly, input like date -d thursday or date -d 'first thursday' or date -d '1 thursday' gives the date of the next Thursday to occur, relative to the current date; similarly, input like date -d 'last thursday' gives the date of the last thursday, relative to the current date. Unfortunately, date doesn't [yet] seem to understand making this particular calculation relative to any other date; it would be nice to write date -d 'jan 1 first thursday last monday 32 weeks' to get the same result).
Slashdot Mirror
The difficulty here is that your parent is trying to maintain 2 histories locally at the same time, which is of course a PITA because git was designed for such a nonsensical usage case. The solution is to automate handling the second history.
For instance, one could just create the 2008 version of the history by rewriting the 2010 history before pushing, which could be achieved with git's `filter-branch' command.
Alternatively, one could implement commit hooks or other scripts that simultaneously create commit objects and manage a second branch by hand using the low-level plumbing tools to actually commit the `solution' and `project' files from some particular revision with the 2008 files (perhaps a commit tagged `v2008' or something). Of course, one has to keep in mind that these will in fact be 2 separate histories, so merge conflicts might crop up between the `solution' and `project' files over time.
Actually, unicode support IS hard to get right.
what if you only want to push/commit parts of the change you made in a given file then ?
You shouldn't conflate committing and pushing.
For committing parts of the change you made in a given file, use `git add -p' to sift through the diff hunks and even edit hunks; `git stash' can also be useful here.
You'd probably also like git's `cherry-pick'.
All assets are in RCS as there are many code changes tied to art assets, they need to be in sync.
Perhaps git's submodule feature would be of service here. From the man page: 'Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.'
The last shipped game that I worked on had a minimum sync size of ~43GB. That did not include movies, design documents, style guides or multiple language support. That built the PC, XBox360 and PS3 SKUs. A full sync was well over 100GB which I never did as I didn't need that stuff.
I wonder whether something like bup (which is based on git) might be useful for managing the large datasets; given that bup stores data in git repos, you could probably even use it as the basis for a submodule (perhaps with the help of scripts to unload the data where desired).
However, I think the main point is that git is optimized for managing code history and that it's kind of silly to expect git or any other tool to handle both usage cases well. When it comes to managing code history alone, git probably provides better tools than what you espouse:
I want my multiple change lists and the ability to sync any file to any revision easily for testing. I want to be able to select someone else's change list and revert it locally without hassle. I just find that git gets in my way when I have shit to do and little time to do it.
You can do all of these things easily with git's `fetch', `log', `whatchanged', `diff', `merge', `show', `checkout', `reset', `stash', `revert', `rebase', etc.
If there's on thing you can do with git, it's slice and dice code and revision history in any which way you please. Frankly, I think you're frustrated because you don't know what you're talking about with regard to git; you've never bothered to learn what you assume is an inferior tool. In reality, the inferiority is your mindset.
Vimperator
What does 'physical thing' even mean? People are always talking about software as though it's intangible and metaphysical. This is because most people don't understand what's going on; they can't see gears and levers and wheels that can be turned by hand, so they assume that some kind of magic is at work.
There is no fundamental difference between the Newcomen steam engine and Linux's latest execution scheduler.
Everything in this Universe is describable with Mathematics/Logic; everything is just information.
Either patents apply to everything or they apply to nothing.
In most cases, it's not copying that is at issue, but rather compensation for the arduous task of finding the original, and I think therein lies the solution: Should the inventor of rounded GUI elements be compensated in the same ways as the inventor of the LCD screen? The contemporary patent problem has to do with preposterously disproportionate entitlement.
LOL
Well, you've brought the discussion full circle: What you don't seem to grasp is that standardization is not about innovation; it's about recognizing long-existing commonality and what has been proven to work or be useful, which is exactly what POSIX does and which is exactly why POSIX leaves some behavior as implementation-defined or even undefined.
The C++0x standard is another good example of standardization done properly; rather than innovate FROM THE STANDARD, it largely just recognizes widely used stuff that has been around IN PRACTICE for a long time (boost libraries, constructs from other languages, usage patterns, design patterns, etc.).
In any case, I see you've declined to justify your example.
My point was simply that you cannot rely on undefined or implementation-defined behavior across implementations. Moreover, part of the purpose of a standard is to provide a centralized delineation of exactly what is defined behavior, what is implementation-defined behavior (including the set of possible implementation choices), and what is undefined behavior; this is far preferable to only having a collection of a myriad of proprietary documentation (most of which is often incomplete).
Now, help me understand your scenario.
Try this on solaris and then try it on hp-ux:
shm_open("/shm-test", O_RDWR, 0600);
It will work on solaris and fail on hp-ux because the underlying mechanism for tracking the shm namespace is undefined by posix, so different vendors have implemented it in "innovative" ways. Posix is riddled with shit like that.
Am I to assume that the shared memory object named "/shm-test" already exists? If it does not, then I would expect a failure with errno set to ENOENT, as per the POSIX:2008 (IEEE Std 1003.1-2008 Base Definitions, Issue 7) documentation.
What are you experiencing that is particularly annoying?
It is, as you say, undefined by POSIX. What's your point? What do you not understand about this?
The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.
Written by someone who has never tried to deploy POSIX standard code on multiple vendor systems.
Written by someone who still doesn't understand the POSIX standard; if a system is POSIX compliant, then you know all of the possible behaviors, because they are listed in the POSIX standard. That's the point.
The nature of standardization is to recognize what is standard; of course POSIX tried to allow every vendor to keep doing their own thing as much as possible. What you're thinking of is innovation.
"Linux"
I do not think that means what you think that means.
Perhaps Fedora but not Suse is running an NTP (Network Time Protocol) client, and perhaps Suse is configured for the wrong time zone or the hardware clock and Suse's configuration don't agree on whether time is stored as local time or as time at UTC offset +0000.
I believe that Google+ allows users to back up all of their data (pictures, posts, whatever), including Google+-specific data like whose in which 'circles'. Can someone correct me?
Some years ago, MIT threw out Scheme in favor of Python because the latter has more 'vocational' merit...
there is currently a legal and practical difference beween on the one hand matter & possessions and on the other information and virtual things.
What does 'virtual thing' even mean? People are always talking about software as though it's intangible and metaphysical. This is because most people don't understand what's going on; they can't see gears and levers and wheels that can be turned by hand, so they assume that some kind of magic is at work.
There is no fundamental difference between the Newcomen steam engine and Linux's latest execution scheduler.
There is no "freedom of possession" which entitles you to have any object you want to have.
The only thing that gives you the "right of possession" is physical violence. The only reason there is the concept of "right of possession" in the first place is the fact that there are limited resources, which simply means that some information is more easily copied than other information.
In most cases, it's not copying that is at issue, but rather compensation for the arduous task of finding the original, and I think therein lies the solution: Should the inventor of rounded GUI elements be compensated in the same ways as the inventor of the LCD screen? The contemporary patent problem has to do with preposterously disproportionate entitlement.
Everything in this Universe is a manifestation of Mathematics/Logic; everything is just information.
Either patents apply to everything or they apply to nothing.
If there were a free market, then the Mafia wouldn't have a monopolistic racket.
While a bitcoin's properties make it seem like a big improvement over conventional currency, the fiat nature of its value cripples it in the same fundamental way; I hope that we figure out how to couple the value of currency with the fundamental laws/constants that define this Universe so that it becomes impossible to abandon it as a measurement of work.
How much of Longsoon's success is made possible only because Intel and AMD wrote the book on processors?
What does that matter?
I'm not sure that really counts as an explanation because there are really excellent films that have ensemble casts rather than a well-defined protagonist. Alien comes to mind.
My comment was only meant as a pointer in the right direction: There are tools which are very helpful.
Moreover, there are various week-numbering standards, each of which defines the first and last weeks of the year differently, making this a more difficult problem when there is no specification.
However, let's assume you want ISO 8601's definition of week 33. Then, the first week of the year is defined as the week with the year's first Thursday, and the first day of every week is Monday. So, let's start with 2011-January-01, or, more succinctly:
Of course, that output format depends on the current locale, so a more definitive version would be:
So, the first day of week 01 in 2011 is:
Thus, the start of week 33 (which is the start of week 01 plus 32 more weeks) would be:
Interestingly, input like date -d thursday or date -d 'first thursday' or date -d '1 thursday' gives the date of the next Thursday to occur, relative to the current date; similarly, input like date -d 'last thursday' gives the date of the last thursday, relative to the current date. Unfortunately, date doesn't [yet] seem to understand making this particular calculation relative to any other date; it would be nice to write date -d 'jan 1 first thursday last monday 32 weeks' to get the same result).