Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"?
* Commits to "documentation" never had a relation to "reactos" commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.
* I don't get the idea of that "rossubsys" directory created in 2014.. These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
* The "wallpapers" directory is a harder candidate. On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.
I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases.
What are your opinions on this?
Cheers,
Colin
Suggestion for modules: cmake properties (and default value): DISABLE_ROSTESTS:bool=false ENABLE_ROSAPPS:bool=false
Since we can call cmake with -DENABLE_ROSAPPS:bool=true in the commandline, to override the default, it's easy to toggle.
As for other modules:
- Documentation deserves its own repository, at github.com/reactos/documentation, where people can more easily contribute documentation separately from code. - Rossubsys: I'd extract them into some git repository at like git.reactos.org/rossubsys.git, for anyone who wants to access them historically, but I wouldn't bother making a github repository for them. - Wallpapers: Would be nice to have a community website where people can submit wallpapers, themes, cursors, icons, ... and the "staff picks" can get copied into modules/wallpapers and included in releases.
On 7 September 2017 at 19:17, Colin Finck colin@reactos.org wrote:
Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"?
- Commits to "documentation" never had a relation to "reactos" commits, so
nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
- The "wallpapers" directory is a harder candidate.
On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.
I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases.
What are your opinions on this?
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
"Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone."
What is it that you feel is lacking? Because I have done similar things, depending on how you frame the issue.
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-09-07 19:26 GMT+02:00 David Quintana (gigaherz) gigaherz@gmail.com:
Suggestion for modules: cmake properties (and default value): DISABLE_ROSTESTS:bool=false ENABLE_ROSAPPS:bool=false
Since we can call cmake with -DENABLE_ROSAPPS:bool=true in the commandline, to override the default, it's easy to toggle.
As for other modules:
- Documentation deserves its own repository, at github.com/reactos/
documentation, where people can more easily contribute documentation separately from code.
- Rossubsys: I'd extract them into some git repository at like
git.reactos.org/rossubsys.git, for anyone who wants to access them historically, but I wouldn't bother making a github repository for them.
- Wallpapers: Would be nice to have a community website where people
can submit wallpapers, themes, cursors, icons, ... and the "staff picks" can get copied into modules/wallpapers and included in releases.
On 7 September 2017 at 19:17, Colin Finck colin@reactos.org wrote:
Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"?
- Commits to "documentation" never had a relation to "reactos" commits,
so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
- The "wallpapers" directory is a harder candidate.
On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.
I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases.
What are your opinions on this?
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 07.09.2017 um 19:26 schrieb David Quintana (gigaherz):
- Rossubsys: I'd extract them into some git repository at like git.reactos.org/rossubsys.git http://git.reactos.org/rossubsys.git, for anyone who wants to access them historically, but I wouldn't bother making a github repository for them.
Please have a look at them. I see nothing more than stubs and no point in a separate repo just for them. A separate repo would even make things worse, because it breaks up all ties with the ReactOS source code. You can only understand why they have .xml build files if you look at the ReactOS code back then..
Let's just remove them in the first commit to the migrated repo and interested parties can still dig into our history.
- Wallpapers: Would be nice to have a community website where people can submit wallpapers, themes, cursors, icons, ... and the "staff picks" can get copied into modules/wallpapers and included in releases.
Yes, that would be nice for the future, but we need a solution for now and the past :) I tend to move them to "modules/wallpapers" and add a CMake variable ENABLE_WALLPAPERS just like for "rosapps" and "rostests". No reason for renaming the directory if a CMake variable can also do the job.
Cheers,
Colin
Yeah that works for now I guess. ;P
On 8 September 2017 at 10:28, Colin Finck colin@reactos.org wrote:
Am 07.09.2017 um 19:26 schrieb David Quintana (gigaherz):
- Rossubsys: I'd extract them into some git repository at like git.reactos.org/rossubsys.git http://git.reactos.org/rossubsys.git, for anyone who wants to access them historically, but I wouldn't bother making a github repository for them.
Please have a look at them. I see nothing more than stubs and no point in a separate repo just for them. A separate repo would even make things worse, because it breaks up all ties with the ReactOS source code. You can only understand why they have .xml build files if you look at the ReactOS code back then..
Let's just remove them in the first commit to the migrated repo and interested parties can still dig into our history.
- Wallpapers: Would be nice to have a community website where people
can submit wallpapers, themes, cursors, icons, ... and the "staff picks" can get copied into modules/wallpapers and included inreleases.
Yes, that would be nice for the future, but we need a solution for now and the past :) I tend to move them to "modules/wallpapers" and add a CMake variable ENABLE_WALLPAPERS just like for "rosapps" and "rostests". No reason for renaming the directory if a CMake variable can also do the job.
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi Colin
How about using links in the local filesystem? On Windows it's possible to use directory links in a similar way to Linux. Starting from Win7 there is a simple native way to do so (the mklink command), but it has already been possible since WinXP (with linkd.exe from the Windows Server 2003 Resource Kit).
It should be possible to keep the modules structure, clone the individual repositories into separate directories locally and link the directories into the target directory with one of the linkd / mklink / ln utilities on the development system. The links can be easily deleted with the normal Windows delete functions if need arises to remove them.
Regards Dimitrij
----- Original Message ----- From: "Colin Finck" colin@reactos.org To: "'ReactOS Development List'" ros-dev@reactos.org Sent: Thursday, September 07, 2017 7:17 PM Subject: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories
Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
Answering to Magnus: In svn it's trivial to checkout a subfolder in an arbitrary location and commit and such from that subfolder. This made it easy to have separate root folders for rostests, rosapps, etc. Doing this in git is non-trivial and even if possible, would require multiple clones, which is not wanted.
Answering to Dimitrij: Using mklink in windows requires administrator privileges. It's not a valid option. And XP didn't have proper symlinks, it had junction points which are not quite the same.
Given to the two reasons above, it's much more effective to permanently move the files to inside the modules folder, where the build system already expects it, and change the check from "folder exists" to "this property/variable is set".
On 7 September 2017 at 22:50, Dimitrij Klingbeil dklingb@gmail.com wrote:
Hi Colin
How about using links in the local filesystem? On Windows it's possible to use directory links in a similar way to Linux. Starting from Win7 there is a simple native way to do so (the mklink command), but it has already been possible since WinXP (with linkd.exe from the Windows Server 2003 Resource Kit).
It should be possible to keep the modules structure, clone the individual repositories into separate directories locally and link the directories into the target directory with one of the linkd / mklink / ln utilities on the development system. The links can be easily deleted with the normal Windows delete functions if need arises to remove them.
Regards Dimitrij
----- Original Message ----- From: "Colin Finck" colin@reactos.org To: "'ReactOS Development List'" ros-dev@reactos.org Sent: Thursday, September 07, 2017 7:17 PM Subject: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories
Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Doesn't submodules do what you need? And, all submodules get cloned automatically if you just add --recursive to the clone command. It all depends on what you mean by arbitrary location. :).
https://github.com/magnusjjj/gfesys/blob/master/.gitmodules
(I will shut up if you feel this is annoying and shit. Not meant as a besserwisser-y shit or no-clue-as-to-situation or something, and don't want to derail the discussion :). Just nerdsniped me since I have been using the functionality a fair bit and also seen other projects use it for things that *sound* similar to what you are talking about)
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-09-07 23:50 GMT+02:00 David Quintana (gigaherz) gigaherz@gmail.com:
Answering to Magnus: In svn it's trivial to checkout a subfolder in an arbitrary location and commit and such from that subfolder. This made it easy to have separate root folders for rostests, rosapps, etc. Doing this in git is non-trivial and even if possible, would require multiple clones, which is not wanted.
Answering to Dimitrij: Using mklink in windows requires administrator privileges. It's not a valid option. And XP didn't have proper symlinks, it had junction points which are not quite the same.
Given to the two reasons above, it's much more effective to permanently move the files to inside the modules folder, where the build system already expects it, and change the check from "folder exists" to "this property/variable is set".
On 7 September 2017 at 22:50, Dimitrij Klingbeil dklingb@gmail.com wrote:
Hi Colin
How about using links in the local filesystem? On Windows it's possible to use directory links in a similar way to Linux. Starting from Win7 there is a simple native way to do so (the mklink command), but it has already been possible since WinXP (with linkd.exe from the Windows Server 2003 Resource Kit).
It should be possible to keep the modules structure, clone the individual repositories into separate directories locally and link the directories into the target directory with one of the linkd / mklink / ln utilities on the development system. The links can be easily deleted with the normal Windows delete functions if need arises to remove them.
Regards Dimitrij
----- Original Message ----- From: "Colin Finck" colin@reactos.org To: "'ReactOS Development List'" ros-dev@reactos.org Sent: Thursday, September 07, 2017 7:17 PM Subject: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories
Hi all!
As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi Magnus,
We had discussed using Git submodules in depth, but using them to keep our current ReactOS modularization would require a separate "reactos.git" and "rostests.git" repository. This comes with many drawbacks:
* A previously single commit modifying "reactos" and "rostests" would now be two unrelated commits to two repos. And on top of the code changes, you would need to change the target hash of the "rostests" submodule in "reactos".
* Creating a branch in "reactos" would not create a branch in "rostests" as well. You would have to replicate branch creation manually and change the submodule target hash again.
We basically introduced the modularization in SVN, because people could decide to just check out "reactos" without the rest, saving disk space, download and build time. With Git, people are cloning the entire history of ReactOS anyway and checkouts are faster, so there is no point about saving disk space and download time anymore. Build time will still be saved by disabling the modules through CMake.
In the future, we may think about using Git submodules or Git subtree for third-party imported components. But let's first migrate to Git ourselves :)
Cheers,
Colin
Am 08.09.2017 um 07:55 schrieb Magnus Johnsson:
Doesn't submodules do what you need? And, all submodules get cloned automatically if you just add --recursive to the clone command. It all depends on what you mean by arbitrary location. :).
https://github.com/magnusjjj/gfesys/blob/master/.gitmodules
(I will shut up if you feel this is annoying and shit. Not meant as a besserwisser-y shit or no-clue-as-to-situation or something, and don't want to derail the discussion :). Just nerdsniped me since I have been using the functionality a fair bit and also seen other projects use it for things that *sound* similar to what you are talking about)
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-09-07 23:50 GMT+02:00 David Quintana (gigaherz) <gigaherz@gmail.com mailto:gigaherz@gmail.com>:
Answering to Magnus: In svn it's trivial to checkout a subfolder in an arbitrary location and commit and such from that subfolder. This made it easy to have separate root folders for rostests, rosapps, etc. Doing this in git is non-trivial and even if possible, would require multiple clones, which is not wanted. Answering to Dimitrij: Using mklink in windows requires administrator privileges. It's not a valid option. And XP didn't have proper symlinks, it had junction points which are not quite the same. Given to the two reasons above, it's much more effective to permanently move the files to inside the modules folder, where the build system already expects it, and change the check from "folder exists" to "this property/variable is set". On 7 September 2017 at 22:50, Dimitrij Klingbeil <dklingb@gmail.com <mailto:dklingb@gmail.com>> wrote: Hi Colin How about using links in the local filesystem? On Windows it's possible to use directory links in a similar way to Linux. Starting from Win7 there is a simple native way to do so (the mklink command), but it has already been possible since WinXP (with linkd.exe from the Windows Server 2003 Resource Kit). It should be possible to keep the modules structure, clone the individual repositories into separate directories locally and link the directories into the target directory with one of the linkd / mklink / ln utilities on the development system. The links can be easily deleted with the normal Windows delete functions if need arises to remove them. Regards Dimitrij ----- Original Message ----- From: "Colin Finck" <colin@reactos.org <mailto:colin@reactos.org>> To: "'ReactOS Development List'" <ros-dev@reactos.org <mailto:ros-dev@reactos.org>> Sent: Thursday, September 07, 2017 7:17 PM Subject: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories Hi all! As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!) _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev <http://www.reactos.org/mailman/listinfo/ros-dev> _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev <http://www.reactos.org/mailman/listinfo/ros-dev>
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
- Commits to "documentation" never had a relation to "reactos" commits, so
nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.
Yeah, I see that as a separate "project" (documentation), separated from the ROS source.
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok. Alternatively, as a separate "project" they can be found... (the "reactos" github account can have other repos I suppose?)
- The "wallpapers" directory is a harder candidate.
On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.
Again, same, it's some heavy multimedia thingie.
But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"?
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be DL'ed into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into "working/rostests" and "working/wallpapers", then symlinks (OK on *nix & windows) into the "working/reactos.git/modules" can be created that point to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Cheers, Hermès
Oh, and I've seen that git clone can take a while to DL the repos.... It seems that both these links : https://stackoverflow.com/questions/3946538/git-clone-just-the-files-please , and https://stackoverflow.com/questions/1209999/using-git-to-get-just-the-latest... give a clue on how to just download the files without the history... (To be tested, although).
H.
-----Message d'origine----- De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Hermès BÉLUSCA-MAÏTO Envoyé : vendredi 8 septembre 2017 14:27 À : 'ReactOS Development List' Objet : Re: [ros-dev] Git Migration: The documentation, rossubsys and wallpapers directories
Hi!
- Commits to "documentation" never had a relation to "reactos"
commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections.
Yeah, I see that as a separate "project" (documentation), separated from the ROS source.
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok. Alternatively, as a separate "project" they can be found... (the "reactos" github account can have other repos I suppose?)
- The "wallpapers" directory is a harder candidate.
On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code.
Again, same, it's some heavy multimedia thingie.
But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"?
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be DL'ed into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into "working/rostests" and "working/wallpapers", then symlinks (OK on *nix & windows) into the "working/reactos.git/modules" can be created that point to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Cheers, Hermès
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that both these links : https://stackoverflow.com/questions/3946538/git-clone-just-the-files-please , and https://stackoverflow.com/questions/1209999/using-git-to-get-just-the-latest...
give a clue on how to just download the files without the history... > [...]
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be DL'ed into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into "working/rostests" and "working/wallpapers", then symlinks (OK on *nix & windows) into the "working/reactos.git/modules" can be created that point to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Both of your ideas destroy the automatic relationship of a specific revision of "reactos" with a specific revision of the modules.
We don't want to start telling people to use that particular version of "reactos" with that particular version of "rostests". It gets even worse if you want to hack on both in a branch.. So matching versions must always stay together, and this is why I want to keep them in a single repository, only enabled/disabled by a CMake variable.
Of course, the logical next step would be overhauling our tree layout. But first things first ;)
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok.
As with every Version Control System, the difficulty of finding deleted files in history boils down to the creativity of your used GUI :)
Shortcut for you to find related commits: git log --name-only | grep -C 5 rossubsys
I have updated my conversion scripts and rules at https://github.com/ColinFinck/reactos-git-conversion-scripts to split off "documentation" into its own repository. Also they now perform the "reactos" directory reorganization and add the "0.4.7-dev" tag for git describe.
Cheers,
Colin
How about having a separate repository for wallpapers, and in 'master' or whatever only have the 'last release' wallpaper + one or 2 alternatives?
The wallpaper repo can then have a structure where there is a folder per release, and an additional folder for potential candidates for next releases.
On 8 September 2017 at 16:47, Colin Finck colin@reactos.org wrote:
Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that both these links : https://stackoverflow.com/questions/3946538/git-clone-just-the-files-please , and https://stackoverflow.com/questions/1209999/using-git-to-get-just-the-latest...
give a clue on how to just download the files without the history... >
[...]
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be DL'ed into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed into "working/rostests" and "working/wallpapers", then symlinks (OK on *nix & windows) into the "working/reactos.git/modules" can be created that point to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Both of your ideas destroy the automatic relationship of a specific revision of "reactos" with a specific revision of the modules.
We don't want to start telling people to use that particular version of "reactos" with that particular version of "rostests". It gets even worse if you want to hack on both in a branch.. So matching versions must always stay together, and this is why I want to keep them in a single repository, only enabled/disabled by a CMake variable.
Of course, the logical next step would be overhauling our tree layout. But first things first ;)
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok.
As with every Version Control System, the difficulty of finding deleted files in history boils down to the creativity of your used GUI :)
Shortcut for you to find related commits: git log --name-only | grep -C 5 rossubsys
I have updated my conversion scripts and rules at https://github.com/ColinFinck/reactos-git-conversion-scripts to split off "documentation" into its own repository. Also they now perform the "reactos" directory reorganization and add the "0.4.7-dev" tag for git describe.
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
what about some "art" repo?
It might have icons, wallpapers, some image and/or video galleries..... (just like Demo images and videos at Windows folders....)
On Fri, Sep 8, 2017 at 7:03 PM, Mark Jansen mark.jansen@reactos.org wrote:
How about having a separate repository for wallpapers, and in 'master' or whatever only have the 'last release' wallpaper + one or 2 alternatives?
The wallpaper repo can then have a structure where there is a folder per release, and an additional folder for potential candidates for next releases.
On 8 September 2017 at 16:47, Colin Finck colin@reactos.org wrote:
Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that both these links : https://stackoverflow.com/questions/3946538/git-clone-
just-the-files-please
, and https://stackoverflow.com/questions/1209999/using-git-
to-get-just-the-latest-revision
give a clue on how to just download the files without the history... >
[...]
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be
DL'ed
into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed
into
"working/rostests" and "working/wallpapers", then symlinks (OK on *nix
&
windows) into the "working/reactos.git/modules" can be created that
point
to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Both of your ideas destroy the automatic relationship of a specific
revision
of "reactos" with a specific revision of the modules.
We don't want to start telling people to use that particular version of "reactos" with that particular version of "rostests". It gets even worse
if
you want to hack on both in a branch.. So matching versions must always stay together, and this is why I want to keep them in a single repository, only enabled/disabled by a CMake
variable.
Of course, the logical next step would be overhauling our tree layout. But first things first ;)
- I don't get the idea of that "rossubsys" directory created in 2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok.
As with every Version Control System, the difficulty of finding deleted files in history boils down to the creativity of your used GUI :)
Shortcut for you to find related commits: git log --name-only | grep -C 5 rossubsys
I have updated my conversion scripts and rules at https://github.com/ColinFinck/reactos-git-conversion-scripts to split
off
"documentation" into its own repository. Also they now perform the "reactos" directory reorganization and add the "0.4.7-dev" tag for git describe.
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hope we will have a wiki page to help the Developers to switch over w/o any hassles.
On Sat, Sep 9, 2017 at 10:20 AM, Javier Agustìn Fernàndez Arroyo < elhoir@gmail.com> wrote:
what about some "art" repo?
It might have icons, wallpapers, some image and/or video galleries..... (just like Demo images and videos at Windows folders....)
On Fri, Sep 8, 2017 at 7:03 PM, Mark Jansen mark.jansen@reactos.org wrote:
How about having a separate repository for wallpapers, and in 'master' or whatever only have the 'last release' wallpaper + one or 2 alternatives?
The wallpaper repo can then have a structure where there is a folder per release, and an additional folder for potential candidates for next releases.
On 8 September 2017 at 16:47, Colin Finck colin@reactos.org wrote:
Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that both these links : https://stackoverflow.com/questions/3946538/git-clone-just-
the-files-please
, and https://stackoverflow.com/questions/1209999/using-git-to-
get-just-the-latest-revision
give a clue on how to just download the files without the history... >
[...]
The builder(s) can have a "working" directory, in which they check-out the different "projects" they need for the build: reactos source can be
DL'ed
into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed
into
"working/rostests" and "working/wallpapers", then symlinks (OK on
*nix &
windows) into the "working/reactos.git/modules" can be created that
point
to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Both of your ideas destroy the automatic relationship of a specific
revision
of "reactos" with a specific revision of the modules.
We don't want to start telling people to use that particular version of "reactos" with that particular version of "rostests". It gets even
worse if
you want to hack on both in a branch.. So matching versions must always stay together, and this is why I want
to
keep them in a single repository, only enabled/disabled by a CMake
variable.
Of course, the logical next step would be overhauling our tree layout. But first things first ;)
- I don't get the idea of that "rossubsys" directory created in
2014..
These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and
remove
them again. You can always find them in our repository history.
As long as they can be found easily in the history, then ok.
As with every Version Control System, the difficulty of finding deleted files in history boils down to the creativity of your used GUI :)
Shortcut for you to find related commits: git log --name-only | grep -C 5 rossubsys
I have updated my conversion scripts and rules at https://github.com/ColinFinck/reactos-git-conversion-scripts to split
off
"documentation" into its own repository. Also they now perform the "reactos" directory reorganization and add the "0.4.7-dev" tag for git describe.
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I suck at writing documentation, but I'm always on IRC ready to help anyone. ;P
On 9 September 2017 at 19:54, James Tabor jimtabor.rosdev@gmail.com wrote:
Hope we will have a wiki page to help the Developers to switch over w/o any hassles.
On Sat, Sep 9, 2017 at 10:20 AM, Javier Agustìn Fernàndez Arroyo < elhoir@gmail.com> wrote:
what about some "art" repo?
It might have icons, wallpapers, some image and/or video galleries..... (just like Demo images and videos at Windows folders....)
On Fri, Sep 8, 2017 at 7:03 PM, Mark Jansen mark.jansen@reactos.org wrote:
How about having a separate repository for wallpapers, and in 'master' or whatever only have the 'last release' wallpaper + one or 2 alternatives?
The wallpaper repo can then have a structure where there is a folder per release, and an additional folder for potential candidates for next releases.
On 8 September 2017 at 16:47, Colin Finck colin@reactos.org wrote:
Am 08.09.2017 um 14:34 schrieb Hermès BÉLUSCA-MAÏTO:> It seems that
both
these links : https://stackoverflow.com/questions/3946538/git-clone-just-t
he-files-please
, and https://stackoverflow.com/questions/1209999/using-git-to-get
-just-the-latest-revision
give a clue on how to just download the files without the history... >
[...]
The builder(s) can have a "working" directory, in which they
check-out
the different "projects" they need for the build: reactos source can be
DL'ed
into "working/reactos.git" ; the wallpapers, rostests etc... can be DL'ed
into
"working/rostests" and "working/wallpapers", then symlinks (OK on
*nix &
windows) into the "working/reactos.git/modules" can be created that
point
to "working/wallpapers" and "working/rostests" , and then we build as usual ?
Both of your ideas destroy the automatic relationship of a specific
revision
of "reactos" with a specific revision of the modules.
We don't want to start telling people to use that particular version of "reactos" with that particular version of "rostests". It gets even
worse if
you want to hack on both in a branch.. So matching versions must always stay together, and this is why I want
to
keep them in a single repository, only enabled/disabled by a CMake
variable.
Of course, the logical next step would be overhauling our tree layout. But first things first ;)
> * I don't get the idea of that "rossubsys" directory created in
2014..
> These subsystems are all stubs, never built with modern ReactOS, and > no work has happened since "reviving" them. I would just go and
remove
> them again. You can always find them in our repository history. > As long as they can be found easily in the history, then ok.
As with every Version Control System, the difficulty of finding deleted files in history boils down to the creativity of your used GUI :)
Shortcut for you to find related commits: git log --name-only | grep -C 5 rossubsys
I have updated my conversion scripts and rules at https://github.com/ColinFinck/reactos-git-conversion-scripts to split
off
"documentation" into its own repository. Also they now perform the "reactos" directory reorganization and add
the
"0.4.7-dev" tag for git describe.
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev