I create a lot of Wikipedia illustrations. I currently host the project 
files and source code on MediaFire. However, if something were to happen 
to me that resource would disappear after 1 year of inactivity.

I am considering using GitHub instead. Presumably it will be around for 
a while. Also, this seems most convenient for people interested in 
looking at the source code.

However, I don't want to create one repository for each illustration. 
And the images are licensed under several different licenses. (Mostly CC 
BY-SA. Some GFDL. Some public domain.) So putting them all in one 
repository might be problematic. Also, using one set of versioning 
records for multiple projects does not seem ideal.

What do you think would the best option for me to pursue? I like what I 
have now, but it (and I) could expire and the files could be lost.


Mike

Post a reply to this message

Am 05.08.2018 um 05:16 schrieb Mike Horvath:
> I create a lot of Wikipedia illustrations. I currently host the project
> files and source code on MediaFire. However, if something were to happen
> to me that resource would disappear after 1 year of inactivity.
> 
> I am considering using GitHub instead. Presumably it will be around for
> a while. Also, this seems most convenient for people interested in
> looking at the source code.
> 
> However, I don't want to create one repository for each illustration.
> And the images are licensed under several different licenses. (Mostly CC
> BY-SA. Some GFDL. Some public domain.) So putting them all in one
> repository might be problematic. Also, using one set of versioning
> records for multiple projects does not seem ideal.
> 
> What do you think would the best option for me to pursue? I like what I
> have now, but it (and I) could expire and the files could be lost.


No recommendation, just a few thoughts for consideration:


Having one repo for each illustration seems a bit overkill to me.


Different licenses in one repo are not an issue - at least not
technically. The display of the license name in the repo's title bar on
GitHub is an optional feature, not a must. If your license file is not
recognized as one of the standard licenses, no license name will be
displayed.

So you could go about the licensing thing by having a global
"LICENSE.txt" or "LICENSE.md" that just says "different licenses apply,
see individual directories", and place an individual license description
in each directory.


I presume that by "versioning records" you mean version numbers.

Git does not feature an inbuilt version number mechanism anyway. Yes,
each commit has a unique identifier which serves as something similar,
but those are more or less random and have no inherent order.

In a normal repository version numbers would be maintained using Git
"tags", by which you can give easier-to-memorize and/or sortable names
to selected commits. Often those tags would just be a version number,
e.g. `v3.8.0-alpha.87654321`.

In a repository hosting a collection of small projects, you could
prepend the name of the changed project to the tag, e.g.
`colorspace-hsl-v2.0`.


Placing multiple scenes in a single repo has the advantage that they can
share files such as include files or texture images.

It also has the advantage that you can add a script to re-render all the
images in one go.


As a last note, don't forget that between "one repository per
illustration" and "one repository to rule them all" there are other
alternatives. For instance, you could use one repo per licensing model;
or you could use one repo per topic, e.g. one repo for all colour models
and a separate repo for all map projections.

Post a reply to this message

I wonder if TortoiseSVN and TortoiseGit are safe to install at the same 
time.

Mike

Post a reply to this message

Am 06.08.2018 um 16:09 schrieb Mike Horvath:
> I wonder if TortoiseSVN and TortoiseGit are safe to install at the same
> time.

I guess so.

As long as you do not put a directory under management of both at the
same time, that is. Otherwise all bets are off.

Post a reply to this message

BTW, my go-to Git front-end is Atlassian's SourceTree. Of all the free
Git front-end software I had tried, it was the one that I felt most
comfortable with, back when I was new to Git myself. All others seemed
confusing and non-intuitive, while this one bridged the knowledge gap
reasonably well for me.

Maybe that's because it didn't orginate in the Git world, but in the
Mercurial world (or so I conjecture; Atlassian is the company behind
Bitbucket, which started out as a Mercurial hosting site before getting
extended to also support Git repos later; SourceTree also supports Hg).

Since I had used TortoiseSVN earlier and was quite happy with it, and
also had experimented with TortoiseHg at some point, I guess TortoiseGit
was also among the tools I tried - but didn't quite get comfy with. I
suspect Explorer extensions - which work great for centralized version
control - don't really lend themselves to the workflow of distributed
version control like Hg or Git.


Another cornerstone of my development / version control workflow is
BeyondCompare, which is a great diff tool. It's a commercial product,
but totally worth its price ($30-$60 depending on edition).

Post a reply to this message

On 08/06/2018 11:02 AM, clipka wrote:
> BTW, my go-to Git front-end is Atlassian's SourceTree. Of all the free
> Git front-end software I had tried, it was the one that I felt most
> comfortable with, back when I was new to Git myself. All others seemed
> confusing and non-intuitive, while this one bridged the knowledge gap
> reasonably well for me.

I like Syntevo's SmartGit.  I came over from SmartCVS.  Nice
visualization tools. Nice integration with github.
Plus, it's Deutscheware. ;)

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Okay, I set it up.

https://github.com/mjhorvath/mike_illustrations

Poke at the files if you want.


Mike

Post a reply to this message