Re: Default folder names compulsory?

At 08:22 AM 12/01/2008, Ryan Schmidt wrote:

>On Jan 11, 2008, at 05:57, an0n1m0us_at_gmail.com wrote:
>
>>Thanks for this, it's very helpful. I've printed the first two
>>chapters of the book and am RTFMing :) The initial quality of the
>>manual is quite impressive!
>>
>>One statement I can make that might clear up some confusion is that
>>I don't care if the names "trunk", "branches" and "tags" are used
>>in the repository's internals and theory. I was just hoping to
>>ensure the trunk always related to code in the /home/username/ folder.
>
>You can check out a working copy to anywhere you want. Checking out
>to the home folder directly might not be the best idea in the world,
>but you can certainly do it:
>
>svn checkout url://to/something/in/your/repository $HOME

Ok, that sounds like what I want but I don't think I've explained the context to you properly.

>Working copies are meant to be disposable. They can get wedged or
>otherwise into weird states, and the answer if you ask on the mailing
>list will often be "delete your working copy and start over." This
>could be inconvenient if you find yourself needing to delete your
>home folder in order to get back to work.

Hmmm, sometimes svn "wedges [the code] ... into weird states" ?

However I think there's a miscommunication re context here. /home/username/ is on the server, it's the project space, the project's VWS username. It's not the local machine's of developers.

>>If this is the case, my scenario would need a situation where any
>>code checked in to the trunk would automatically be outputted to a
>>real folder. If I was to draw up a basic work flow diagram of what
>>I am trying to achieve, would you be able to take a look?
>
>
>You probably don't want to automatically update users' working
>copies.

As above, this isn't what I was intending. I was hoping to update a project's output space on the development server.

>Users should be in control of when and if to update their
>working copies. The book will explain this, I'm sure.

Yeah I understand working copies on developers machines are best controlled by developers.

>It sounds like you're maybe not versioning regular source code
>projects? What are you versioning?

Website code. Our current workflow is:

Setup a Virtual Web Server (VWS) account for a customer (aka user, aka project) in the development server's home directory. Something like this:

http://devel.projecta.org/

would point to

/home/projecta/public_html/

on the development server.

Developers simply log in from their workstations via FTP and work carte blanche (in reality the only two developers currently sit next to each other and communicate re which files we touch) on any file by downloading it to our workstation, modifying, saving the changes (uploading) and previewing immediately via the above URL.

When a site is ready to go live, it is manually moved via FTP from the development server to a production server which is usually mapped to a corresponding VWS with a URL like:

http://www.projecta.org/

What is lacking here is backup (aka versioning), collaborative development without relying purely on developer communication and a simplified way to move or merge development code from the development server to the production server. Eventually there might be a staging server in between as well. However that's not something I'm prepared to worry about just yet.

Hope this clears up the context/model of what I'm hoping we can set up.

Thanks for your continued help.

pd

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-13 06:12:47 CET