On 13 Sep 2007, at 16:08, Hans-Christoph Steiner wrote:
A cool thing I've been doing recently with the externals feature
is using them more like symlinks; so for portaudio you can put the
revision you want to stay static in a central location ( e.g. /
svnexternals/portaudio) and then
On 14 Sep 2007, at 05:23, Hans-Christoph Steiner wrote:
One last comment on this topic: since SVN is supposed to handle moves
so well, why don't we defer the very contensious issues of
reogranizing the directories and tags/branches until after we have
the SVN repository working nicely? It
Hans-Christoph Steiner wrote:
Plus, what about adding Gem back to the main pure-data repository?
why?
- everything else is in that repository
?
- makes for one checkout for everything
see my random mentions of svn:externals
- makes it easy to make branches and tags for the whole
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an
experimental branch of pd-extended to re-work the entire build-system
into small (managable) pieces that are modular and survive directory
re-structuring.
i know that you are not really interested
On Sep 13, 2007, at 12:06 AM, Luke Iannini (pd) wrote:
Does SVN handle this differently?
yes and now.
yes: you don't _have_ to create a tag and a branch whenever you
import code.
no: you can import code that is maintained elsewhere into a branch,
a tag, the trunk (or just any other
On Wed, 12 Sep 2007, IOhannes m zmoelnig wrote:
i don't see a reason why desiredata should move out again into a
separate repository, unless they wish to do so.
I don't see a reason either. I don't know why Hans is suggesting that.
Perhaps it has to do with access control, but I don't
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
If you want so much to remove existing tags and branches, what is that a
sign of? Is SVN appropriate for handling projects that have many tags
and branches?
why should svn be
On Sep 13, 2007, at 5:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an
experimental branch of pd-extended to re-work the entire build-
system into small (managable) pieces that are modular and survive
directory
On Sep 13, 2007, at 4:49 PM, Mathieu Bouchard wrote:
On Wed, 12 Sep 2007, IOhannes m zmoelnig wrote:
i don't see a reason why desiredata should move out again into a
separate repository, unless they wish to do so.
I don't see a reason either. I don't know why Hans is suggesting
that.
On Sep 13, 2007, at 5:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
however, once we have moved to SVN i would like to make an
experimental branch of pd-extended to re-work the entire build-
system into small (managable) pieces that are modular and survive
directory
Hans-Christoph Steiner wrote:
As for 'scripts', there needs to be a place for all the scripts needed to
build Pd-extended. Whether that's also the place for bash_completion,
etc, that's a separate question.
but since it is the pd-repository rather than the pd-extended
repository, it
Hans-Christoph Steiner wrote:
#TAGS:misc
import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~)
These tags are useful for handling imported code that is maintained
elsewhere.
thats what the documentation says.
have you ever made any use of the useful thing?
Does SVN
Hello,
I just missed the pdconv, so how is the authorization for the repository
planed ? Is it possible to restrict access to a subfolder ?
If so I would recommend to put the trunk, tags, branches as subfolder of
projects which can be deligated rather then have a very long list of versions
Winfried Ritsch wrote:
Hello,
I just missed the pdconv, so how is the authorization for the repository
planed ? Is it possible to restrict access to a subfolder ?
no, since the plan is to stay with sourceforge for now, there is still
no way to restrict write access to submodules (afaik).
hello,
I just missed the pdconv, so how is the authorization for the repository
planed ? Is it possible to restrict access to a subfolder ?
no, since the plan is to stay with sourceforge for now, there is still
no way to restrict write access to submodules (afaik).
If so I would
Hallo,
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think externals is exactly the name: it means pd stuff
that does not come with pd itself, rather than pd-objects written in C
How about extensions? Somehow the word externals has sunken in as
meaning binary
On 12/09/2007, at 20.50, Frank Barknecht wrote:
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
personally i think externals is exactly the name: it means pd
stuff
that does not come with pd itself, rather than pd-objects
written in C
How about extensions? Somehow the
Hallo, yes. The appropriate way to handle this IMO is to do the initial
conversion (thus creating the many directories), then do an svn rm for those
tags that are abandoned or unnecessary. Tags and Branches in SVN are great
because they can have lifetimes - you can make your branch to try some
On Sep 12, 2007, at 4:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Sounds good, how about downcasing while you are at it, so we have
it more standardized.
i don't see a real benefit from it.
but then: why not?
(and finally: since Framestein is really abandoned for
On Sep 12, 2007, at 4:22 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
#TAGS:misc
import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui
zhzxh~)
These tags are useful for handling imported code that is
maintained elsewhere.
thats what the documentation says.
Does SVN handle this differently?
yes and now.
yes: you don't _have_ to create a tag and a branch whenever you
import code.
no: you can import code that is maintained elsewhere into a branch,
a tag, the trunk (or just any other directory)
yes: svn is able to handle references to
hi.
after the talk about svn at the pd-con, it seems like there is a general
ok from the community, if somebody would be willing to perform the
actual migration.
actually i could be this volunteer.
ad miller: there exist migration paths from both cvs and svn to git, so
svn would do no harm
Hi,
sounds very reasonable to me.
The only potential problem that i see is the flat hierarchy (resp.
naming scheme) of the branches and tags. It seems that this folder
would populate quite fast and might quickly become a mess. On the
other hand it's quite easy to clean it up again with svn
Am 11.09.2007 um 17:04 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Hi,
sounds very reasonable to me.
The only potential problem that i see is the flat hierarchy
(resp. naming scheme) of the branches and tags. It seems that
this folder would populate quite fast and might quickly
Am 11.09.2007 um 19:58 schrieb Mathieu Bouchard:
- desiredatapd-devel live beside pd (not in a separate branch)
If Thomas hasn't changed his mind, pd-devel is going to be obsolete
soon. The latest changes still have to be picked up from there and
moved somewhere else, such as sf.net
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon.
The latest changes still have to be picked up from there and moved
somewhere else, such as sf.net patchtracker and the desiredata branch, but
for all
Mathieu Bouchard wrote:
On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote:
- moved abstractionsextensionsxguiFramestein into externals
good thing, as long as abstractions does not become a subfolder of
externals... but I would rather have it under a common name that isn't
abstractions nor
27 matches
Mail list logo