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(a)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-lates…
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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev