Re: IMPORTANT: It's time to migrate from CVS (your input needed)

On 30 November 2017 at 04:55, Philipp Hahn <[email protected]> wrote:
> Hi,
>
> Am 30.11.2017 um 05:34 schrieb Robert Eden:
>> On Nov 29, 2017 6:55 PM, "Nick Morrott" <[email protected]
>> <mailto:[email protected]>> wrote:
>>>
>>>     On 30 November 2017 at 00:52, Nick Morrott
>>>     <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>     > Assuming the repo migration is okay, we can then move to migrating
>>>     > relevant tickets and populating the wiki.
>>>
>>>     One more thing - once we're happy to start committing to git we need
>>>     to remove the CVS $Id strings from grabber/library version numbers
>>>     etc. I can get that done over the weekend if all goes well.
>>
>> Does git have something similar?
>
> Yes: `man 5 gitattributes` → "export-subst" and "filter"
>
> But most often it is not worth the hassle.

+1.

We could set up smudge/clean filters to try and mimic the CVS $Id
thingy, but do we actually need to? It is worth pointing out that
whilst in CVS where each file has a given revision number, in git all
files are tied to the revision of the repository as a whole.

As I see it, the use-case for almost all end users is that they
install/update XMLTV via a package manager (or download an exe) which
has packaged the latest stable release of the project. All libraries
and utilities are distributed together, and all are tied to
$XMLTV::VERSION, which is the only version number that matters and is
incremented at release time. A grabber could emit something like
"XMLTV/tv_grab_zz_sdjson version 0.5.70" and for users running
packaged stable releases that is all the information we need.

Users that do clone from git going forwards will always be able to
give the revision of the project they are testing, which is
straightforward to check locally for a developer. These details could
be included in an issue template [1] which a user completes when
creating an issue on github.

  [1] https://help.github.com/articles/creating-an-issue-template-for-your-repository/

I am not a fan of the recent trend of versioning individual libraries
within the project - it creates another developer overhead to
maintain, and when versions are not incremented it looks as though an
out-of-date version of a library has been included. Including the
development log/changes in the source code itself is also not
appropriate, and is what the VCS is for. Ideally when we decide on how
to handle grabber versioning this can be addressed too.

Cheers,
Nick

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
xmltv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xmltv-devel