Re: [oll-user] Repository organization

[Urs L. <ul...@op...>]

Am 12.04.2013 14:13, schrieb Janek Warchoł:
> Time to catch up with some things..
>
> 2013/4/5 Joseph Rushton Wakeling <jos...@we...>
>
>> But if you are concerned,
>> the simplest way is just to give up the idea of one-repo-to-rule-them-all
>> and
>> have a few different repositories to cover different parts of the project.
>>
>> It's zero added complexity for users of the project, as one can always
>> bundle
>> everything together in one big .tar.gz file for user download; it adds some
>> complexity for developers/contributors but also reduces complexity in
>> other ways.
>>
>> So, I would start by modularizing the project appropriately into different
>> repos
>> without worrying about submodules, and think about introducing them later
>> if
>> that seems to be necessary.
>>
> This sounds reasonable.  As long as we don't have more than a few repos in
> a flat directory structure, that shouldn't be very complicated to execute.
> If we encounter problems, we can fix them in the future.
> Janek
I also thought this is reasonable. We should probably have separate 
repos for
- the LilyPond library
- common LaTeX stuff (that is necessary to compile documents)
- tutorials
- web site
- lilyglyphs
- musicexamples
- (lilydoc [if it should come into existence ...])

But it seems not so easy to separate the repositories regarding their 
history.

I tried to rip off a musicexamples repository but failed so far.
First I made a copy of the existing repo and restored the old history 
that had been stuffed away in the archive tag. This worked quite well, 
and I'm very happy I did that.

Then I tried to extract the history for the musicexamples directory with 
git filter-branch --directory-filter, and this didn't work:
- filter-branch --directory-filter works only for files that are in that 
dir _currently_
commits with files that have been moved into at some time are not included
-> the oldest transfered commit was consequently titled 'move to 
musicexamples dir' ,-)
- reason for that is:
- filter-branch pulls the directory to the root level
- if a file had been moved from a directory _above_ the target of 
--directory-filter
it would end up being considered as outside the git repository

My research regarding the other filters didn't turn up a solution, at 
least none that I'd realized/understood.

I could log the history of the files with --follow which would include 
the history across renames. But this works only for singe files, not a 
directory.

An approach I could imagine is to recursive loop over all files in the 
directory and store all commits for each one, then merge these lists to 
one to remove duplicates, finally apply them all, maybe with cherry-pick 
on a new branch.
Of course this would be rather simple for example with Python, but I 
have to admit I'm not quite ready for such a thing.
And I don't quite see the implications of different branches for this 
approach yet.

So it remains open:
Any ideas how to deal with the situation?

The simplest solution would be:
- Just remove all files except the ones needed for the new repo with a 
regular commit
- Move all remaining files to the desired new location in the directory 
structure, also with a regular commit.
Absolutely painless process, but of course each repo would carry the 
whole history.

Second simplest solution:
- Add only the desired files to the new repos
- Keep the existing repo as the only instance of the history.

I don't like both.

Urs
> -------------- next part --------------
> An HTML attachment was scrubbed...
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user