Git Migration: The documentation, rossubsys and wallpapers directories

[Colin Finck]

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

[David Quintana (gigaherz)]

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 [e-mail] 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Johnsson]

"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) [e-mail]:
> 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 [e-mail] 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

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

[David Quintana (gigaherz)]

Yeah that works for now I guess. ;P

On 8 September 2017 at 10:28, Colin Finck [e-mail] 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 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
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Dimitrij Klingbeil]

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" [e-mail]
To: "'ReactOS Development List'" [e-mail]
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!)

[David Quintana (gigaherz)]

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 [e-mail] 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" [e-mail]
> To: "'ReactOS Development List'" [e-mail]
> 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[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) [e-mail]:
> 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 [e-mail]
> 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" [e-mail]
> > To: "'ReactOS Development List'" [e-mail]
> > 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

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) <[e-mail] 
> mailto:[e-mail]>:
> 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 <[e-mail]
> <mailto:[e-mail]>> 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"
>     <[e-mail] <mailto:[e-mail]>>
>     To: "'ReactOS Development List'" <[e-mail]
>     <mailto:[e-mail]>>
>     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
>     [e-mail] <mailto:[e-mail]>
>     http://www.reactos.org/mailman/listinfo/ros-dev
>     <http://www.reactos.org/mailman/listinfo/ros-dev>
>
>
>
> _______________________________________________
> Ros-dev mailing list
> [e-mail] <mailto:[e-mail]>
> http://www.reactos.org/mailman/listinfo/ros-dev
> <http://www.reactos.org/mailman/listinfo/ros-dev>
>
>
>
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Hermès BÉLUSCA-MAÏTO]

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

[Hermès BÉLUSCA-MAÏTO]

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:[e-mail]] 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

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

[Mark Jansen]

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 [e-mail] 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Javier Agustìn Fernàndez Arroyo]

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 [e-mail] 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 [e-mail] 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
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

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 <
[e-mail]> 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 [e-mail]
> 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 [e-mail] 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
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[David Quintana (gigaherz)]

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 [e-mail] 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 <
> [e-mail]> 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 [e-mail]
> > 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 [e-mail] 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
> > > > [e-mail]
> > > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev