Re: Default folder names compulsory?
Date: Sun, 13 Jan 2008 21:31:11 +1100
At 04:31 PM 13/01/2008, you wrote:
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
Woohooo! Thanks for that.
>I've just never heard of having server-side "users" representing each
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.
>>>Users should be in control of when and if to update their
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
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
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
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
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
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
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
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
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
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:
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.
This is an archived mail posted to the Subversion Users mailing list.