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 < elh...@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.jan...@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 <co...@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 >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
