Re: Default folder names compulsory?

At 04:31 PM 13/01/2008, you wrote:
>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:
>>>
>>>>2Thanks 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."

Hmm, doesn't give me a huge degree of confidence in the reliability of svn, however I thank you for your honesty.

>>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

Woohooo! Thanks for that.

>I've just never heard of having server-side "users" representing each
>project. I suppose there's nothing wrong with that.

It doesn't seem to be a problem for us. This set up has been in place for the best part of 190 years. The /home/username/ accounts on our development server are actually just a convention really as customers do not have access to them. On the production server though, it's a bit tricky for us to develop a website, store it in a user's space and map their URL to it, then when they want to FTP in themselves to make a change down the track (which is their prerogative though we discourage it if we3 are maintaining their site), point them to a different spot on the server.

/home/username/ or /home/username/public_html/ may be a strange place to store websites but it has worked for us over time. Having a separate customer user account and storage folder, on top of their website folder, would be less efficient I think, especially for backing up and so on. A separate list would have to be maintained of which folders belong to which users.

Nevermind.

>>>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.

Well almost all files would be in the public_html folder but there are a few files related to the website that are best stored hidden from public view. Files such as those that store DSN credentials. Ideally we'd like to version those too.

>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.

I think that is true: the subversion repository does not have to be stored in a user's home directory. We just felt this might be simpler and therefore cleaner.

This taps into our other question of whether to use separate repositories for each project. It may be a significant overhead but on the other hand it could have advantages of keeping project information separated from other projects. If we open one repository and have each project as a separate 'space' (not sure of the svn terminology here) then what is to stop other projects from 'spying' on other projects if we open up our repository to a web tool like trac?

>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.

Yep this is a possibility I guess. It's just somewhat more obfuscated then keeping everything in one spot.

>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.)

Yep thanks, I think we're 'on the same page' now. The repositories can be stored anywhere because they can always be versioned (?) to anywhere on the 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.
>
>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.

That sounds about right. I'm not sure about 'working copies' on the server side though. This might be a terminology semantic thing but I would like for the post-commit script to update the project/users preview copy with the current trunk code on the devel server, I think. A nightly script could create a staging or production 'branch' for moving to the other servers, perhaps.

I suppose I'm a little confused by the difference between a 'working copy' that a developer would use on their machine, and what the committed code on the server represents in terms of the trunk, branches and tags terminology.

>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.

Yeah this seems to be the model with desktop software but it's not how we work. One disadvantage of that approach is decentralising the config. Each developer's machine would always have to be updated regularly to mirror any changes to the server config and that would be over the top administratively I think. FWIW we are talking about just two core developers with rare assistance from less than a handful of other people. This is not to say that any system we set up should not be scalable though.

>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.

Wooohooo, that's what we're after. The auto-update FAQ you mentioned above seems like the way to go, I'll definitely read that.

>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.

Ok, as above, I'm not too sure about where the trunk, branches, and especially 'tags' come into this. In terms of 'breaking' code -> making mistakes that temporarily result in the post-commit, auto-update 'preview' version losing functionality, that is ok as we expect that once is a while.

I think the model of copying a 'branch' of the development code to a staging and/or production server when the development version is ready, makes most sense to me. I'm just not 100% sure how this fits in with the SVN trunk, branch, tags situation.

>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.

This is an interesting option. First thing I notice it is that it could make URL paths a PITA. I'll have to give this some thought. It would be a substantial change for us but if it's worth doing, it's worth doing.

>>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.

Ah, this is when I realise replying to email as I read it is a bad thing :) Ok so "tag"s fit in this way. Hmmm, interesting. I'm not sure exactly how we would be doing trunk and branching but that might be clearer once I decide on a more definite set up of the development side of things.

The only example I have to follow in this whole thing is the diagrams I've seen of Firefox development schedules. Like this:

http://www.mozilla.org/roadmap/branching-2004-05-28.png

The ongoing code base they work on is the trunk, whereas releases are branches. I'm not sure that this differentiation is necessary for web work, or at least in the development workflow I am trying to perfect.

---------------------------------------------------------------------
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 11:49:35 CET