On Jan 12, 2008, at 23:12, an0n1m0us_at_gmail.com wrote:
> 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" ?
[the working copy], yes. Working copies can become messed up, and
they are considered disposable. Be prepared to be told "delete your
working copy and check out a new one."
> 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.
Ok, thanks, that does make more sense. And that's a perfectly normal
thing to do. There's even a FAQ that discusses setting up server-side
working copies for the purpose of previewing web sites:
http://subversion.tigris.org/faq.html#website-auto-update
I've just never heard of having server-side "users" representing each
project. I suppose there's nothing wrong with that.
>> 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.
So then public_html is the working copy, not the home directory
itself. That's better.
But you're not accessing it via
http://www.example.com/~projecta/
? Then it doesn't even need to be in a particular server-side
"user"'s directory. All working copies could just live in a central
area on the server:
/www/projecta
/www/projectb
etc. Nobody other than the sysadmin will ever need to access these
files or know where they are; they will be touched solely by the post-
commit script of the repository which will auto-update them following
each commit. So it doesn't matter where they live. (They can also
stay where they are now, I'm just saying there's no reason to
introduce the overhead of creating a new server-side "user" for each
new project, and spreading the server-side working copies out in
different "user" directories.)
> 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.
Then your new workflow is that each developer gets a working copy of
the project on their own machine, works on it, tests it, and commits
it when done. A post-commit script you write takes care of updating
the server-side working copies.
Ideally the developer has Apache and all other necessary web software
running on his development machine so that he can test the web site
before committing. If this is not possible, the user can certainly
make a change, commit it, then check the result on the server, then
tweak it and commit again and check again, repeating until it's
correct. But this will likely have the effect of breaking the project
during the developer's development work. One usually strives to keep
the trunk working correctly. You may want to consider using branches
for developer work in this case.
Or, another alternative entirely is to store each developer's working
copy (or working copies) on the server, in the developer's
public_html directory. This is how the web development shop where I
worked did it. So on the server we had:
/home/rschmidt/public_html/projecta/trunk
/home/jdoe/public_html/projectc/branch_1_0
I could then access my working copy of the projecta trunk via
http://www.example.com/~rschmidt/projecta/trunk
I could work on these files by logging into the server via ssh and
working in vi, or I could mount my server-side public_html to my
client workstation via SMB or similar and work on it in my favorite
GUI editor. When done with a change, I can commit it.
> 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/
Your new strategy should then involve making a "tag" of the trunk
when you're ready to go live with a site. Then, on the production
server, you check out a copy of the tag from the repository.
> 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.
---------------------------------------------------------------------
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:32:28 CET