working in teams..

in most cases, we work in teams..

me and someone else are working on code logic, while a developer or  
two work on the stylesheets..

we tie this together with svn..

can this kind of teamwork happen in seaside?

what is the mechanism?

thanks!


___
peace,
sergio
photographer, journalist, visionary
www.village-buzz.com



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I can use moticello like svn, but moticello is better.

Regards



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/10/22 sergio <[hidden email]>:
SVN for CSS / images / JS.

Monticello (local http repository) for Seaside code.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Oct 24, 2008, at 5:19 AM, Philippe Marschall wrote:

>> what is the mechanism?
>
> SVN for CSS / images / JS.
>
> Monticello (local http repository) for Seaside code.

can someone explain exactly why this is the way you would want to do it?

if you need to keep css, images etc in sync with smalltalk code,

tagging, branching etc then this seems like a non starter.

what do you really gain from the 2 repo split?

how do people work around it?

do you check monticello packages into svn when branching, tagging etc is
done to keep everything together in one place?

just not worry about it from the tech side and use a 'human solution'?


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 25-Oct-08, at 8:06 AM, Sean Allen wrote:

>

> if you need to keep css, images etc in sync with smalltalk code,
>
> tagging, branching etc then this seems like a non starter.


It's just more convenient. Versioning Smalltalk in SVN is a hassle and  
vice-versa, but dealing with two versioning systems isn't so bad. I  
find that keeping the Smalltalk code in sync with everything else just  
isn't an issue. They tend to evolve independently, and when you do  
need to do it, it's not difficult.

As a versioning nerd, I understand the concern, but I haven't found it  
to be a problem in practice.

Colin
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi!

Small hint here. We are developing in VASt. One way to version external
files in ENVY, we use at our costumer, is creating a class named like
the external file resource (eg. STYLECSS) this can be imported or
exported to and from ENVY. The file contents is converted to string, or
binary, versioned and stored directly in ENVY. So we are able to version
even external files in the Smalltalk repository....

I think that might also be able for other Smalltalks...

Cheers!
Sebastian

       
               
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I did something similar for StORE a few years ago.  It used a pragma in the method to define the path name of the external file, with the file contents stored right after the pragma.  The VW UI was extended to support keeping the external file and the method synchronized.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Oct 25, 2008, at 2:51 PM, Colin Putney wrote:

> It's just more convenient. Versioning Smalltalk in SVN is a hassle  
> and vice-versa, but dealing with two versioning systems isn't so  
> bad. I find that keeping the Smalltalk code in sync with everything  
> else just isn't an issue. They tend to evolve independently, and  
> when you do need to do it, it's not difficult.
>
> As a versioning nerd, I understand the concern, but I haven't found  
> it to be a problem in practice.

Do you do anything to keep them in sync or is it just a process thing?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 25-Oct-08, at 4:00 PM, Sean Allen wrote:

> Do you do anything to keep them in sync or is it just a process thing?

Just process.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside