2

We've got several RHEL5 development servers, one for each developer. Each server is developer's own sandbox, with Subversion checkout available through Samba shares (having RHEL5 clients is out of option, corporate policy requires Windows XP). Now several developers have notebooks as main development boxes and would like to have their code available even when there's no network connectivity, e.g. in the presentation room or at home. R/W preferred, of course, but R/O would do too.

I'm thinking about some system with transparent persistent caching, lie a virtual drive which would synchronize with the original share when online and replace the network drive when offline. There are possibly other solutions, what would you recommend?

EDIT: Judging from the comments, I notice how difficult it is to explain what we are doing. I'll just try again. There is a central SVN repository and developers' devel-boxes to work on. However, they are not allowed to use those boxes as Linux clients directly, but instead they need to use Windows XP as development client because of corporate restrictions. So the webserver stays on the RHEL5 devel-box (which is reference platform), checkout stays there too and is shared to the developer via Samba (exclusively!). There is no misunderstanding of what SVN is and isn't, it's just that the checkouts are located on the server and not on the client. Because of that, they are not available online, but it's desired that they are -- and this has been the essence of my question.

Tell me if this is easier to understand :)

1
  • I'VE GOT IT! You're not using subversion in a client/server setup, are you? Your developers each have their own subversion repository, not their own branches! Am I right? Oct 26, 2009 at 16:09

4 Answers 4

1

I like Matt Simmons' suggesting re: using your version control system. Having said that, if it's not practical for some reason, look at "Offline Files" in your Windows XP clients. I've been using "Offline Files" against Samba for a few years. Some versions had various silly problems, but if you're running newer versions (I don't know what version RHEL5 ships with) you should be fine.

1
  • This could be it, looks like my best guess. Thanks Oct 26, 2009 at 16:16
1

It sounds to me like you might be missing the general idea behind subversion (forgive me if I am wrong). It looks like you are trying to reinvent something that subversion already does by default.

Normally, from what I have seen and used, you make a repository with code or documents in it. Then each developer 'checks out' their own local copy. This local copy is stored on their hard drive. When they are done, they check in their copy, and the changes they have made are uploaded.

Introducing another layer with SAMBA doesn't make much sense to me, unless maybe it was to have some read-only version available to non technical people.

1
  • Samba share contains the checkout and is also wired into apache. This way a developer can see his changes immediately. Samba is used because developers don't run Apache on their Windows, but instead it's run on the RHEL5 boxes running those shares. Oct 26, 2009 at 16:15
1

I keep some of my writing in a subversion repository, and I use tortoiseSVN as a subversion client on my Windows machine. Have you considered having them checkout the repository there, and maybe giving them a "laptop development" branch or something, into which they can merge changes and then folding them into their other development efforts?

4
  • +1 - I'd keep everything in your version control repository. TortoiseSVN is very, very nice, as well. Oct 26, 2009 at 15:54
  • Yes, the whole checkout via Samba share seems bizarre, why not just have the developers check it out directly? Oct 26, 2009 at 15:56
  • That's not the problem. They do want to have their code in SVN, but they also want to have that code available offline, outside of the test environment. Basically, a second checkout, which is ideally synchronized to the actual share when online. Oct 26, 2009 at 15:56
  • 1
    When you check something out, you make a local copy of it. Oct 26, 2009 at 16:03
1

It sounds to me like your workflow would be better matches using a Distributed Version Control System (DVCS), such as Bazaar, Git, or Mercurial. These systems all allow you to work offline (such as while travelling), and still make commits and continue your work.

I believe that the three DVCS I listed will allow you to continue using subversion in the back end (with a little extra effort), and likely offer guides on migrating from subversion.

2
  • 1
    I really suspect that the submitter is just Doing It Wrong(tm) and not actually using svn like it should be used. Oct 26, 2009 at 16:52
  • DVCS is a no-go. I would have preferred it too... Oct 26, 2009 at 20:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .