Hi!
There was some discussions about switching from SVN to git. I don't
remember everything but a major blocker was that it is not possible to
checkout a subtree with git and managing a lot of git repositories will
make it difficult to do global changes to the "global" repository.
There i
On Sun, Mar 6, 2011 at 11:12, Vincent Bernat wrote:
> Hi!
>
> There was some discussions about switching from SVN to git. I don't
> remember everything but a major blocker was that it is not possible to
> checkout a subtree with git and managing a lot of git repositories will
> make it dif
OoO En ce début d'après-midi nuageux du dimanche 06 mars 2011, vers
14:48, Sandro Tosi disait :
>> There was some discussions about switching from SVN to git. I don't
>> remember everything but a major blocker was that it is not possible to
>> checkout a subtree with git and managing
On Sun, Mar 6, 2011 at 14:07, Vincent Bernat wrote:
> Do you think this is an acceptable solution? Commit can be done on
> several repositories with one command. This is not really a single
> commit, but maybe close enough. Maybe this was already discussed.
I don't know.
--
Sandro T
On Mar 06, 2011, at 12:12 PM, Vincent Bernat wrote:
>There was some discussions about switching from SVN to git. I don't
>remember everything but a major blocker was that it is not possible to
>checkout a subtree with git and managing a lot of git repositories will
>make it difficult to do
On Sun, 06 Mar 2011, Barry Warsaw wrote:
> if the latter, then I would much prefer to see debian-python choose a
> Python-based dVCS.
because ...
^^^ -- please replace with advantages of having dVCS match
underlying language of the packaged work
--
=-
On Sun, Mar 6, 2011 at 17:33, Barry Warsaw wrote:
> Is this a Debian-wide decision, or can each subteam go its own way?
each team can decide on its own, but git is very wide accepted within
Debian, which is to be considered when choosing a new VCS to use
(because it presents a lower barrier to at
On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>Do the 2 VCDs you mentioned have clear advantage that make then
>preferible to git except being Python-based? If so, I think it's a
>quite weak reason.
Let me turn that around: why would you *not* want to use a Python based dVCS?
One reason coul
On Sunday, March 06, 2011 12:43:23 pm Sandro Tosi wrote:
> On Sun, Mar 6, 2011 at 17:33, Barry Warsaw wrote:
> > Is this a Debian-wide decision, or can each subteam go its own way?
>
> each team can decide on its own, but git is very wide accepted within
> Debian, which is to be considered when c
Barry Warsaw writes:
> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>
>>Do the 2 VCDs you mentioned have clear advantage that make then
>>preferible to git except being Python-based? If so, I think it's a
>>quite weak reason.
>
> Let me turn that around: why would you *not* want to use a Pyth
On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman wrote:
...
> reasonably comfortable for both. It's not as fast a git and it suffers from
> not being able to do partial checkouts (like git), so it's very much a middle
> ground in both advanatages and disadvantages between svn and git.
I believe t
Robert Collins wrote:
>On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman
>wrote:
>...
>> reasonably comfortable for both. It's not as fast a git and it
>suffers from
>> not being able to do partial checkouts (like git), so it's very much
>a middle
>> ground in both advanatages and disadvantages b
On Mon, Mar 7, 2011 at 8:09 AM, Scott Kitterman wrote:
> Robert Collins wrote:
>
>>On Mon, Mar 7, 2011 at 7:52 AM, Scott Kitterman
>>wrote:
>>...
>>> reasonably comfortable for both. It's not as fast a git and it
>>suffers from
>>> not being able to do partial checkouts (like git), so it's very
On Sun, 06 Mar 2011, Scott Kitterman wrote:
> One thing that is a clear advantage for bzr is that it supports both a
> traditional centralized workflow and modern DVCS workflow so that not
> everyone
> needs to switch to a foreign method of work immediately after the transition.
>
AFAIK any
Hi Piotr,
On Mon, Feb 07, 2011 at 10:27:06AM +0100, Piotr Ożarowski wrote:
> [³] http://wiki.debian.org/Python/support2dhp2
Just a small note here about this wiki page name. :) This doesn't fit
typical wiki naming conventions, and it's entirely impervious to searching
on keywords like "dh_python
On Sun, Mar 06, 2011 at 01:48:32PM +, Sandro Tosi wrote:
> On Sun, Mar 6, 2011 at 11:12, Vincent Bernat wrote:
> > There was some discussions about switching from SVN to git.
CPython just switched to mercurial.
Mercurial works well with multiple repositories (subrepo extension)
and handl
On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
> Let me turn that around: why would you *not* want to use a Python based dVCS?
>
Because the language of a tool shouldn't usually matter at all?
Because git-buildpackage is widely used while mercurial-buildpackage is
not?
--
WBR, wRA
On Sunday, March 06, 2011 03:02:25 pm Yaroslav Halchenko wrote:
> On Sun, 06 Mar 2011, Scott Kitterman wrote:
> > One thing that is a clear advantage for bzr is that it supports both a
> > traditional centralized workflow and modern DVCS workflow so that not
> > everyone needs to switch to a foreig
On Mon, Mar 07, 2011 at 01:56:59AM +0500, Andrey Rahmatullin wrote:
> On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
> > Let me turn that around: why would you *not* want to use a Python based
> > dVCS?
> >
> Because the language of a tool shouldn't usually matter at all?
> Because
Hello,
i have started to package a series of modules for scipy.
These are put on the namespace as
scikits.timeseries
scikits.statsmodels
etc.
I correctly created backages.
But upon installation I get the following error:
sudo dpkg -i ../python-scikits-statsmodels_0.2.0_i386.deb
(Reading databas
Hi,
On Sun, 06.03.2011 at 16:01:04 -0500, Scott Kitterman
wrote:
> With bzr the transition from svn is a little easier than that. Almost any
> svn
> command you would use, the same command works with bzr, e.g. svn co and bzr
> co.
I can confirm that bzr-svn works much more smoothly than gi
Hi,
On Sun, 06.03.2011 at 13:33:45 -0500, Barry Warsaw wrote:
> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
> >Do the 2 VCDs you mentioned have clear advantage that make then
> >preferible to git except being Python-based? If so, I think it's a
> >quite weak reason.
>
> Let me turn that ar
On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>
> >Do the 2 VCDs you mentioned have clear advantage that make then
> >preferible to git except being Python-based? If so, I think it's a
> >quite weak reason.
>
> Let me turn that ar
On Sun, 06 Mar 2011, Steve Langasek wrote:
> please *do* use the pristine-tar options.
just 0.1cents to complement:
although I like pristine-tar in general, if in transition decision would
be to adopt svn-buildpackage mergeWithUpstream ('overlay' in
git-buildpackage) to lightweight the repositor
On Sun, Mar 06, 2011 at 10:55:31PM +0100, Toni Mueller wrote:
> On Sun, 06.03.2011 at 16:01:04 -0500, Scott Kitterman
> wrote:
> > With bzr the transition from svn is a little easier than that. Almost any
> > svn
> > command you would use, the same command works with bzr, e.g. svn co and bzr
On Sun, 06 Mar 2011, Nicolas Chauvat wrote:
> > > There was some discussions about switching from SVN to git.
> CPython just switched to mercurial.
And Cython just switched from mercurial to GIT, having previousely
switched got HG from SVN IIRC... may be that is a logical generic
roadwork? ;)
On Sun, Mar 06, 2011 at 11:15:39PM +0100, Jan Dittberner wrote:
> On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
> > On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
> > >Do the 2 VCDs you mentioned have clear advantage that make then
> > >preferible to git except being Python-based
On Sun, 06 Mar 2011, Steve Langasek wrote:
> frankly. Perhaps you're comparing bzr merging with the seemingly common git
> practice of discarding revision history as a substitute for doing an actual
> DVCS merge?
could you enlighten me how GIT merges manage to discard revision
history? that is s
Hi @All, please accept one consideration,
I've observed that you are using SVN repositories on multi-project
way. In this case,
if you'd want migrate to Git or BZR (I'll use the last one as inline
examples), you must consider the different behavior of the source tag
managing.
#. In SVN, tags are
On Sun, 06 Mar 2011, Tim Michelsen wrote:
> i have started to package a series of modules for scipy.
> These are put on the namespace as
> scikits.timeseries
> scikits.statsmodels
> etc.
ah cool --
$> wnpp-check statsmodels
python-scikits-statsmodels (RFP - #570604)
if of any help, my packagin
[Yaroslav Halchenko, 2011-03-06]
> git diff ... | patch; git commit -m 'Merged blah bleh into blue'
hint: git merge --squash
PS `svn log | egrep "^r[0-9]+ " | cut -f2 -d'|' | sed
's/pox-guest/piotr/;s/kitterma-guest/kitterman/;s/-guest//' | sort | uniq -c |
sort -n -r`
results are here: http://
moreover, while talking about tags, in GIT some symbols we use for
debian versioning (e.g. ~ and :) are not allowed in tags, so they get
replaced (with '%' and '.' for above with git-buildpackage). That is
the only kind of cons I see in switching to GIT.
>lost the comfort of manipulate/move/
On Sun, 06 Mar 2011, Piotr Ożarowski wrote:
> > git diff ... | patch; git commit -m 'Merged blah bleh into blue'
> hint: git merge --squash
ah, evil evil evil git developers for allowing such a thing! I never
used it ;-)
> Sandro: so... what do WE choose? :-)
> mr + git-buildpackage + overlay?
On Monday 07,March,2011 06:44 AM, Piotr Ożarowski wrote:
> [...]
> (it's not that anyone else will do the work anyway - few tried to
> convince us to switch to $VCS and I didn't hear from them after asking
> to start preparing it)
If we switch to git, I'd volunteer to help out with the transitions
On Mon, 07 Mar 2011, Chow Loong Jin wrote:
> stuff there because the git-buildpackage merge-with-upstream workflow doesn't
> work very well with git-svn.
any specific concerns? works for me ok with cython
--
=--=
Keep in touch
On Monday 07,March,2011 07:59 AM, Yaroslav Halchenko wrote:
>
> On Mon, 07 Mar 2011, Chow Loong Jin wrote:
>> stuff there because the git-buildpackage merge-with-upstream workflow doesn't
>> work very well with git-svn.
>
> any specific concerns? works for me ok with cython
Merging history gets
On Mar 07, 2011, at 01:56 AM, Andrey Rahmatullin wrote:
>On Sun, Mar 06, 2011 at 01:33:45PM -0500, Barry Warsaw wrote:
>> Let me turn that around: why would you *not* want to use a Python based dVCS?
>>
>Because the language of a tool shouldn't usually matter at all?
Unless of course you want to
On Mar 06, 2011, at 05:53 PM, Yaroslav Halchenko wrote:
>
>On Sun, 06 Mar 2011, Piotr Ożarowski wrote:
>> > git diff ... | patch; git commit -m 'Merged blah bleh into blue'
>> hint: git merge --squash
>
>ah, evil evil evil git developers for allowing such a thing! I never
>used it ;-)
I've heard
On Mar 07, 2011, at 08:28 AM, Robert Collins wrote:
>For clarity, the thing I'm referring to is the ability to commit
>directly to a stacked branch - which I think is equivalent to the
>partial limitation you're referencing. I've just checked in #bzr, and
>that is in 2.3.0, which has been out for
On Mar 06, 2011, at 08:55 PM, Arto Jantunen wrote:
>I used to choose tools based on the language they are implemented in, I
>justified it with the old "it needs to be in a language I know/like in
>case I need to modify it or fix bugs in it" excuse. Since then I learned
>my lesson and, unless I'm s
ah -- I never tried to dive that deep as in committing git merges back
into SVN. Whenever I am interacting with SVN I am trying to be gentle
with the repository -- just linear changes ;)
On Mon, 07 Mar 2011, Chow Loong Jin wrote:
> >> stuff there because the git-buildpackage merge-with-upstream w
On Monday 07,March,2011 10:13 AM, Yaroslav Halchenko wrote:
> ah -- I never tried to dive that deep as in committing git merges back
> into SVN. Whenever I am interacting with SVN I am trying to be gentle
> with the repository -- just linear changes ;)
My point was that I was using the merge-with
Thank you Barry,
yes -- I see the use-case/purpose for such a feature now, just
hadn't chance to use it myself. But I would not consider it as an
argument for bad practices in GIT ecosystems -- different projects,
communities, contribution gateways -- different rules. Great to see GIT
providing
> I think it's a waste of space to keep the
> tarballs separate from the tree.
which you will do anyways at least for a moment (noone escaped
from the fact of needing .orig.tar.gz yet), but might not be needed for
the long run.
So, if you carry about 100s of packages at once, carrying complete
d
On Monday 07,March,2011 10:22 AM, Yaroslav Halchenko wrote:
>> I think it's a waste of space to keep the
>> tarballs separate from the tree.
>
> which you will do anyways at least for a moment (noone escaped
> from the fact of needing .orig.tar.gz yet), but might not be needed for
> the long run.
On 03/06/2011 07:33 PM, Barry Warsaw wrote:
> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:
>
>> Do the 2 VCDs you mentioned have clear advantage that make then
>> preferible to git except being Python-based? If so, I think it's a
>> quite weak reason.
>
> Let me turn that around: why would yo
On 03/06/2011 12:12 PM, Vincent Bernat wrote:
> Hi!
>
> There was some discussions about switching from SVN to git. I don't
> remember everything but a major blocker was that it is not possible to
> checkout a subtree with git and managing a lot of git repositories will
> make it difficult
Le 06/03/2011 23:30, Yaroslav Halchenko a écrit :
> On Sun, 06 Mar 2011, Nicolas Chauvat wrote:
>> Mercurial works well with multiple repositories (subrepo extension)
> ah thanks -- at times I need to look at HG repos, and I could not figure
> out how to get multiple 'remotes'
I don’t think git re
48 matches
Mail list logo
