> On Monday, August 13, 2012 at 7:53:32 PM UTC+3, andrea crotti wrote:
>> I am in the situation where I am working on different projects that
>> might potentially share a lot of code.
>>
>> I started to work on project A, then switched completely to project B
>> and in the transiction I copied ove
On Monday, August 13, 2012 at 7:53:32 PM UTC+3, andrea crotti wrote:
> I am in the situation where I am working on different projects that
> might potentially share a lot of code.
>
> I started to work on project A, then switched completely to project B
> and in the transiction I copied over a lot
2012/8/16 andrea crotti :
>
>
> Unfortunately I think you guess wrong
> http://forums.perforce.com/index.php?/topic/553-perforce-svnexternals-equivalent/
> Anyway with views and similar things is not that hard to implement the
> same thing..
I'm very happy to say that I finally made it!
It took
2012/8/16 Jean-Michel Pichavant :
>
> SVN allows to define external dependencies, where one repository will
> actually checkout another one at a specific version. If SVN does it, I guess
> any decent SCM also provide such feature.
>
> Assuming our project is named 'common', and you have 2 projects
andrea crotti wrote:
2012/8/14 Cameron Simpson :
Having just skimmed this thread, one thing I haven't quite seen suggested is
this:
Really do make a third "utilities" project, and treat "the project" and
"deploy" as separate notions. So to actually run/deploy project A's code
you'd have a sh
> In plus I'm using perforce which doesn't have any svn:externals-like
You can probably use views to this
(http://www.perforce.com/perforce/r12.1/manuals/cmdref/o.views.html).
> Second problem is that one of the two projects has a quite insane
> requirement, which is to be able to re-run itself o
Also looking at logilab-common I thought that it would be great if we
could actually make this "common" library even open source, and use it
as one of the other many external libraries.
Since Python code is definitively not the the core business of this
company I might even convince them, but the
2012/8/14 Cameron Simpson :
>
> Having just skimmed this thread, one thing I haven't quite seen suggested is
> this:
>
> Really do make a third "utilities" project, and treat "the project" and
> "deploy" as separate notions. So to actually run/deploy project A's code
> you'd have a short script tha
On 13Aug2012 17:53, andrea crotti wrote:
| I am in the situation where I am working on different projects that
| might potentially share a lot of code.
|
| I started to work on project A, then switched completely to project B
| and in the transiction I copied over a lot of code with the
| corresp
2012/8/14 Jean-Michel Pichavant :
>
> I can think of logilab-common (http://www.logilab.org/848/)
>
> Having a company-wide python module properly distributed is one to achieve
> your goal. Without distributing your module to the public, there's a way to
> have a pypi-like server runnning on your p
On Mon, 13 Aug 2012 17:53:32 +0100, andrea crotti wrote:
> I started to work on project A, then switched completely to project B
> and in the transiction I copied over a lot of code with the
> corresponding tests, and I started to modify it.
>
> Now it's time to work again on project A, but I don
andrea crotti wrote:
I am in the situation where I am working on different projects that
might potentially share a lot of code.
I started to work on project A, then switched completely to project B
and in the transiction I copied over a lot of code with the
corresponding tests, and I started to
2012/8/13 Rob Day :
> I'd just create a module - called shared_utils.py or similar - and import
> that in both projects. It might be a bit messy if there's no 'unifying
> theme' to the module - but surely it'd be a lot less messy than your
> TempDirectory class, and anyone else who knows Python wil
On Tue, Aug 14, 2012 at 2:53 AM, andrea crotti
wrote:
> The problem is that there are functions/classes from many domains, so it
> would not make much sense to create a real project, and the only name I
> could give might be "utils or utilities"..
There's actually much merit in a generic utilitie
I'd just create a module - called shared_utils.py or similar - and import
that in both projects. It might be a bit messy if there's no 'unifying
theme' to the module - but surely it'd be a lot less messy than your
TempDirectory class, and anyone else who knows Python will understand
'import shared_
I am in the situation where I am working on different projects that
might potentially share a lot of code.
I started to work on project A, then switched completely to project B
and in the transiction I copied over a lot of code with the
corresponding tests, and I started to modify it.
Now it's ti
16 matches
Mail list logo
