RE: Disconnected Checkout - Best practices?

"Eric Sink" <[email protected]>
Newsgroups gmane.comp.version-control.sourcegear-vault.user
Message-ID <[email protected]>
 
You can use CVS mode in the main GUI client and
still use exclusive checkouts for the project
files.

CVS mode is actually a vague term which we use
to refer to several different options.  Have a
look at the Concurrent Development Style
pane of the options dialog in the main GUI
client.

When you click the CVS mode button, you get:

Auto-commit is off.
Require checkout is off.
Always request exclusive locks is off.
Make all files writable.

If you click the VSS button, you get
the reverse of all these.

What you probably want is a combination of
them.  Here's what I think you want:

Auto-commit should be off.  Things will go
into your pending change set and you can
commit them in groups together as you are
ready.

Require checkout should be off.  Note that
Vault still allows you to checkout, but you
don't have to.

Change the Make Writable setting to
"Make binary files read-only".  This actually
means that all files which are considered
mergable will be writable, but all other files
will be read-only, thus forcing you to check
them out.

Always request exclusive locks should be ON.
In other words, in those cases when you *do*
checkout a file, you want the lock to be
exclusive.

Finally, make sure all your project files are
marked non-mergable.  You can do this on a per-file
basis, or you can use the admin tool to configure
that particular suffix as a non-mergable file.

This group of settings should give you a CVS
mode which you can use effectively for
disconnected operation.

Note however, that the problems you are having
with the work disconnected feature in Visual
Studio still need to be investigated.  I've
logged a bug to remind us to look into it.

--
Eric Sink
Software Craftsman
http://software.ericsink.com/
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Josh Robinson
Sent: Monday, January 05, 2004 4:22 PM
To: [email protected]
Subject: RE: [vault-list] Disconnected Checkout - Best practices?

I would use CVS mode, except that because of the project files we prefer to exclusive checkout enabled.  I will give you a basic scenario detailing how I go about attempting to Work Offline, and the problem that I keep having.
 
1.) Close Visual Studio at work like any other day
2.) When home, load visual studio, open project which I had been working
3.) Select File|Source Control|Change Source Control
4.) Select all projects in my solution, click the disconnect button
5.) Perform work at home in disconnected state
6.) Arrive at work on Monday morning, Open project, re-connect to Server using opposite of steps in step 3
7.) Attempt to check-in changes
Now, this is where the problem is.  When I try to check in changes, it will overwrite all the changes that I made over the weekend from the data in the repository.  It won't even tell me what file is being overwritten, just the directory that it is in.  I have lost changes this way 3X's now, so have become very frustrated.  Is there a better way to do this, for example should I be using the Vault Client?  Any help is appreciated.  Thanks,

Josh

	-----Original Message----- 
	From: Eric Sink [mailto:[email protected]] 
	Sent: Mon 1/5/2004 9:24 AM 
	To: [email protected] 
	Cc: 
	Subject: RE: [vault-list] Disconnected Checkout - Best practices?
	
	


	I assume you're talking about the Work Offline
	feature in Visual Studio.  We don't have any
	set of best practices for using this particular
	feature.  If you can give us some more specific
	information about the problem you're having,
	we might able to help.
	
	BTW, the best way to work disconnected is to use our
	so-called "CVS Mode".  Unfortunately, this way of
	working is supported only in the main Vault client,
	not within Visual Studio.
	
	In this "mode", Vault doesn't require files to be
	checked out before you edit them.  It automatically
	notices your changes and places them in your pending
	change set as if you had checked them out.  We
	sometimes call this "CVS mode" since it implements
	the "edit-merge-commit" model of development which
	is similar to the way CVS works.  Anyway, this is
	a great way to do development when you're not
	connected to the server.
	
	--
	Eric Sink
	Software Craftsman
	http://software.ericsink.com/
	
	-----Original Message-----
	From: [email protected]
	[mailto:[email protected]] On Behalf Of Josh Robinson
	Sent: Monday, January 05, 2004 6:35 AM
	To: [email protected]
	Subject: [vault-list] Disconnected Checkout - Best practices?
	
	We use Vault 1.2.2 for our small dev team here at work.  It is a huge
	improvement from the constant frustrations that we faced with VSS over the
	years.  However, I have lately become so frustrated with the Disconnected
	Checkout (or Work Offline?) feature as to find it unusable and can no longer
	feel confident that any work I perform over the weekend will make it into my
	source control at the office.
	
	It is likely that I am doing something wrong, so rather than give gory
	details about each step that I am doing (which I will gladly do), I would
	love for someone (at SourceGear or otherwise) to run through the steps that
	are required in a disconnected check-out scenario.  Then, (and this is the
	critical part) what are the steps to properly re-connect to the Vault on
	Monday morning without losing all your inspired weekend code.  That is the
	weak link for me right now, I keep losing everything when I come in on
	monday morning.  I hate to say it, but never had trouble with this feature
	of VSS, so I'm sure that I'm just doing it wrong with Vault.  Thanks for any
	help!
	
	Josh
	
	_______________________________________________
	vault-list mailing list
	[email protected]
	http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list
	

Xf)+-ֽXX(˺r櫉 X(˺r櫉rj)fj b˝?륶X
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.