Quoting Janek Warcho? (janek.lilyp...@gmail.com):
> Actually, it is possible to pull from each other - there is no
> technical need for a central "master repository" (that's what being a
> distributed Version Control System means). Of course this can be
> cumbersome for projects with many participants, but if there's only a
> couple of people involved it should work smoothly.
Janek, you are right, that is possible. But for the scenario and policy I
was describing, I don't think that's desirable.
What I wanted is three things:
- Save often, save early policy. I want to be allowed to (locally!) check
in (commit) my changes often, even in intermittent states that might not
even compile, let alone look acceptable.
- Whatever project state you pull from your co-workers, it needs to comply
with the minimum requirements (compile, look acceptable, ...). That
means, they are (and I am) only allowed to publish when their work is
in acceptable form.
- As much independence of workflows between collegues as possible.
I want to do updates whenever *I* am ready to deal with possible clashes
(means whenever my local version is comparably clean), not when my
collegue just reached a point to publish.
When I pull the current (official) state of the project, I do *not* want to
debug my collegue's current work! That's OK for bugs he cannot find. But
not for things he only broke because he's just currently doing a change
there.
So if I want to combine those requirements, I need some mechanism to ensure
updates are only made from the publishable states, not from intermittent
states. Of course there's a lot of ways to accomplish that. Branches come
to mind for example.
But I thought (and think) the 'master repository' approach is the easiest
way to do that, especially if not all involved want to dig into the
workings of the repository tool. And who wants? Usually you just want a
tool to do the job... In addition the 'master repository' approach makes
things like automated daily builds easier, and that might help in quality
control.
Susan
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
