On Thu, May 24, 2012 at 01:24:11PM +0800, James Harkins wrote:
Not sure if this was already discussed (I've been following the thread
somewhat loosely), but it seems to me that git makes it a whole lot
easier to handle a build token by virtue of the repositories being
decentralized.
Yes, it
Am 24.05.2012 10:57, schrieb Colin Hall:
On Thu, May 24, 2012 at 01:24:11PM +0800, James Harkins wrote:
Not sure if this was already discussed (I've been following the thread
somewhat loosely), but it seems to me that git makes it a whole lot
easier to handle a build token by virtue of the
Hi,
On Thu, May 24, 2012 at 10:57 AM, Colin Hall colingh...@gmail.com wrote:
How about Urs, Susan, you and I collaborating on a one-page score
via github as a way of confirming our understanding, and demonstrating
how it can be done? Even a few staves would be enough to confirm a suitable
Dear Urs,
It's astonishing - like reading a good book, but one written with my
specific questions in mind :-)
:-)
What I will have to see in action before really being able to believe it
works in 'real life' is the merging of text files that have been changed
by more than one person. Of
Hi Susan and Urs,
On Wed, May 23, 2012 at 10:43 AM, Susan Dittmar susan.ditt...@gmx.de wrote:
When you are done with your portion of work and all is in an acceptable
state again, then you can pull what others did change in the mean time from
a master repository. This master repository is just
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,
On Wed, May 23, 2012 at 1:09 PM, Susan Dittmar susan.ditt...@gmx.de wrote:
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
Hi,
as I just stumbled over this again, a small hint concerning commits:
ALWAYS add a commit message, even if it is just intermittent state or
even automated checkin. At least with subversion, the log will only list
revisions with changes if they have a commit message. If you leave that
message
On Wed, May 23, 2012 at 7:13 PM, Susan Dittmar susan.ditt...@gmx.de wrote:
Hi,
as I just stumbled over this again, a small hint concerning commits:
ALWAYS add a commit message, even if it is just intermittent state or
even automated checkin. At least with subversion, the log will only list
Not sure if this was already discussed (I've been following the thread
somewhat loosely), but it seems to me that git makes it a whole lot
easier to handle a build token by virtue of the repositories being
decentralized.
I admit, I'm not an svn expert and it's quite likely there are some
svn
Dear Urs,
I think what Colin meant by build token is another strategy to archieve
the same as what I described with checkin/merge to the main branch and
personal development branches. I think he has in mind a decentralized
version control tool, where you first work with your local version,
Dear Susan,
I think this makes sense (although I can't tell if it really is what
Colin wanted to express ...).
Do I understand correctly that what you describe is one possible
strategy to take care of the integrity of the main source tree?
And another one would be what I have the impression
Hi Urs,
On Tue, May 22, 2012 at 01:42:14AM +0200, Urs Liska wrote:
Am 22.05.2012 00:53, schrieb Colin Hall:
On Mon, May 21, 2012 at 11:13:54PM +0200, Urs Liska wrote:
In the meantime I had already decided to go this way for the next
projects. Our current project that we organize with a
On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote:
Dear Susan,
I think this makes sense (although I can't tell if it really is what
Colin wanted to express ...).
It was pretty close. Thanks, Susan, you write well.
Do I understand correctly that what you describe is one possible
Hi Colin,
thanks for your patience. I somehow start to see some light ;-)
Am 22.05.2012 10:53, schrieb Colin Hall:
On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote:
Dear Susan,
I think this makes sense (although I can't tell if it really is what
Colin wanted to express ...).
It was
On Tue, May 22, 2012 at 11:23:34AM +0200, Urs Liska wrote:
thanks for your patience. I somehow start to see some light ;-)
Good!
Am 22.05.2012 10:53, schrieb Colin Hall:
On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote:
Do I understand correctly that what you describe is one
If we'd use the 'build token' concept (be it through empty emails or
'lock files') then we're basically where we are right now (with a shared
folder): tell the others which file I'm going to edit and ask them to
leave this alone for a while.
It looks similar, but there are big differences!
Dear Susan,
thank you very much for taking so much of your valuable time.
It's astonishing - like reading a good book, but one written with my
specific questions in mind :-)
Well basically everything really is very much what I had expected it to be.
What I will have to see in action before
On Tue, May 22, 2012 at 11:47 PM, Urs Liska li...@ursliska.de wrote:
What I will have to see in action before really being able to believe it
works in 'real life' is the merging of text files that have been changed by
more than one person. Of course it's clear that it _must_ work (everything
Dear Urs,
I just have one thing to add to the discussion: *do* use one of the
repository tools! No matter which one (you had some suggestions already),
but do use one! I do so since about 10 years (csv originally, converted to
subversion some -- more than 6, I think -- years ago), and even for
2012/5/21 Susan Dittmar susan.ditt...@gmx.de:
Dear Urs,
I just have one thing to add to the discussion: *do* use one of the
repository tools! No matter which one (you had some suggestions already),
but do use one!
I'd like to add just one more idea. You could use a CVS such as Git,
and maybe
Hi,
On Mon, May 21, 2012 at 11:56 AM, Susan Dittmar susan.ditt...@gmx.de wrote:
One thing you will have to think about is check-in policy though. I
personally like to check in very often, but that means the checked in
version might not compile, let alone be in a state acceptable to use.
I
Dear Susan,
thank you for the valuable input.
What you describe is basically what I thought how it works - but didn't
know for sure due to lack of experience.
Especially the aspect of branching is interesting, as I didn't really
have an idea about that.
So what you describe as the intention of
Hi Urs,
In addition to version control your team may need the concept of a
build token.
The person holding the token has the right to merge in their latest
work and, in so doing, break the project. They also have the
responsibility to leave it in a working state before releasing the
token for
Am 22.05.2012 00:53, schrieb Colin Hall:
Hi Urs,
In addition to version control your team may need the concept of a
build token.
The person holding the token has the right to merge in their latest
work and, in so doing, break the project. They also have the
responsibility to leave it in a
On Thu, May 17, 2012 at 12:36:35PM +0200, Christian Andersson wrote:
Now, sit down and await all flames from proponents of all the other tools!
Saving different versions of files to floppy disks and writing a
label in a thick pen was good enough for us in 1986. Especially
when we re-used a
Il 19/05/2012 19:47, Bernardo Barros ha scritto:
On 05/19/2012 09:47 AM, Federico Bruni wrote:
If you want to keep the easy to use interface, you can use SparkleShare,
free alternative to Dropbox:
http://sparkleshare.org/
Free in what sense? Do they encrypt your data, in a way that only the
From: Graham Percival gra...@percival-music.ca
On Thu, May 17, 2012 at 12:36:35PM +0200, Christian Andersson wrote:
Now, sit down and await all flames from proponents of all the other tools!
Saving different versions of files to floppy disks and writing a
label in a thick pen was good
Am 20.05.2012 09:25, schrieb James Harkins:
From: Graham Percivalgra...@percival-music.ca
On Thu, May 17, 2012 at 12:36:35PM +0200, Christian Andersson wrote:
Now, sit down and await all flames from proponents of all the other tools!
Saving different versions of files to floppy disks and
On 12-05-20 12:39 AM, Graham Percival wrote:
On Thu, May 17, 2012 at 12:36:35PM +0200, Christian Andersson wrote:
Now, sit down and await all flames from proponents of all the other tools!
Saving different versions of files to floppy disks and writing a
label in a thick pen was good enough for
On 05/19/2012 11:46 PM, Federico Bruni wrote:
Free as Free Software (GPL).
SparkleShare is a software, not a hosting service (even though it may
become also a hosting service, see sparkleshare.net).
It looks very nice, you can use with your own server via ssh. It seems
to use git behind the
Il 17/05/2012 13:11, Francisco Vila ha scritto:
2012/5/17 Urs Liskali...@ursliska.de:
OK, but please keep in mind everybody that I specifically asked for the use
with lilypond projects ...
It's no need to be specifically for lilypond to be perfect for
lilypond. It only has to be perfect for
On 05/19/2012 09:47 AM, Federico Bruni wrote:
If you want to keep the easy to use interface, you can use SparkleShare,
free alternative to Dropbox:
http://sparkleshare.org/
Free in what sense? Do they encrypt your data, in a way that only the
owner have access to it?
--
Bernardo Barros
Hi,
I'm using git as well to write notes for my ensemble and host them on
github[1]. There's at least one more person hosting notes there
(actually, contributing for the Mutopia project)[2] so I believe it's
pretty common to use a VCS tool of someone's choice. You may browse
the links and get the
Congratulations for touching upon a hot subject, pretty much like asking
people what text editor to use, something that has been debated for decades
without any objective conclusion.
Personally I tend to prefer git, not only for lilypond score projects, but
for anything text-oriented. This is
Hi list,
I wonder how other people manage their sources in larger lilypond projects.
Currently I'm working on a project whose source folders contain ~300
files, most of them LilyPond source files.
One thing I really have come to love LilyPond for during this project is
the fact that several
Am 17.05.2012 12:36, schrieb Christian Andersson:
Congratulations for touching upon a hot subject, pretty much like
asking people what text editor to use, something that has been debated
for decades without any objective conclusion.
Personally I tend to prefer git, not only for lilypond score
2012/5/17 Urs Liska li...@ursliska.de:
OK, but please keep in mind everybody that I specifically asked for the use
with lilypond projects ...
It's no need to be specifically for lilypond to be perfect for
lilypond. It only has to be perfect for text files, and git is.
You can set up a project
38 matches
Mail list logo
