lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Source management tools for lilypond projects


From: Susan Dittmar
Subject: Re: Source management tools for lilypond projects
Date: Wed, 23 May 2012 13:09:39 +0200
User-agent: Mutt/1.5.9i

Quoting Janek Warcho? (address@hidden):
> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]