[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Checkout to SAMBA 3.5.6 share

From: Wayne Johnson <wayne_at_zk.com>
Date: Thu, 3 Mar 2011 10:23:33 -0800

I am very confused.

> > On 03.03.2011 12:39, Felix Saphir wrote:
> > > Am 03.03.2011 12:26, schrieb Felix:
> > >>
> > >> I use Tortoise SVN 1.6.12 on windows. After a recent upgrade
> > from Debian
> > >> Lenny to Squeeze (including an upgrade of SAMBA from 3.2.5
> 3.5.6)
> > >> checkouts to shares on the SAMBA server fail with a message
> > similar to this:
> > >

You are checking to a network share...

> >
> > I do not share working copies between different operating
> systems.
> > The reason for which they are on a network share is backup.
> >

For a backup.

> >
> Of course I have a SVN server running. But the SVN server is not a
> of 'backup server', i.e. I do not want to commit something just for
> being backed up.
> Don't worry, the repositories themselves get backup-ed every day using
> svanadmin with the hotcopy command.

But what you backing up is not checked in?

How is checking out to a network share going to backup things that you
haven't checked in? There must be some sort of step missing here.

If you are making copies of your code to back it up you are not taking
full advantage of version control. Version control makes it easy to
annotate your 'backups' and also provides simple ways to compare to
different 'backup'. As a bonus you can easily switch between versions
and they don't take up as much room and you don't have to worry about
losing anything. I like to check in multiple times a day (sometimes
multiple times an hour) to capture what I am doing. That way when I
accidentally break the code I am working on I can check was I have
changed quickly. I have employed several strategies:

1. Create a personal branch in Subversion. This works very well and with
the merge tracking stuff it very easy to synch your stuff with the root
path and then merge it back. The downside is that it creates a lot of
'noise' in the subversion database. We use a bug tracking system that
integrates with subversion and it's not real easy to filter out this

2. Checkout from subversion and then turn the working copy into a git
repository. Now check in as often as you want. You can even tag things
and make branches or whatever. When you ready check you finished changes
into subversion. Now backing your working copy is as easy as creating a
remote git repository. Offers that same benefits as personal branches
without the 'noise' in the database. The downside is that there is some
extra work but not that much.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-03-03 19:23:43 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.