[cvsnt] Re: Checkout Error using NT and a network drive aslocalfolder

[Bo Berglund]

A comment on your discussion concerning revisions:
The recommended (and only) way to keep a tab on which files are a combined
file set that works is to use the tag function of CVS. Note that revisions
of files change unsynchronized to each other so you will not be able to
manually keep track of this.
But tagging is really NOT a complex operation either...

In WinCvs just select the top node of the project folder tree,
then click the blue 'T' button and enter the tag text in the box.
Then click OK and you are done. Can't be much simpler than this?

When at a later time you want to come back to this snapshot just do this:
- Select the same top node as before
- Click the green down arrow button
- Go to the 'Update options tab'
- Click the checkbox 'Retrieve data/tag/branch'
- Enter the tag name in the combobox or click the button to the right of
  it if you want to make it easier by browsing the existing tags
- Click OK

Now CVS will get you the *exact* same files as were in the project when
the tag was put there. This is not really very difficult either?

When you are done checking the old version you can go back to the most
recent one by this:
- Select the same top node as before
- Click the green down arrow button
- Check the checkbox 'Reset any sticky date/tag/k options
- Click OK

Now CVS will bring you up to date again.

Note that you cannot edit and commit any files when the files have been
moved back in time to an earlier tag. If you want to do that you need to
create a 'branch' after you updated to the old tag. See documentation on
how to use branches.

/Bo


-----Original Message-----
From: Torsten van Beeck [mailto:torsten.van.beeck at ip-team.de]
Sent: den 28 februari 2003 11:02
To: John Peacock
Cc: cvsnt at cvsnt.org
Subject: [cvsnt] Re: Checkout Error using NT and a network drive
aslocalfolder



Hello John,

>> We have a similar web development scenario and the difference to normal
>> development is that it is much easier to install a compiler on each
>> developers box than a complete webserver. Webserver installations tend
>> to be done centrally.
>
> Have a test web server, with it's own sandbox, and only update the
> production site when you are completed.  This is the only way to sanely
> handle large updates, since you frequently cannot incrementally change
> the site.

thank you for your comprehensive description. Unfortunately my problem is 
somewhat different. We do not want to update the production machine with 
cvs, for that we have a cms solution. The php developer only work on a test 
webserver. So the usual way to do updates is like:

1. edit a page
2. reload page in browser to check if your change solves the problem or 
your addition is ok
3. fix some bugs
4. reload/check again

Due to the nature of web development you repeat step 3 and 4 a couple of 
times before the php and especially the html code is ok. If you have to 
commit every time to iterate step 3 and 4 there are a lot of version in the 
repository which are only intermediate steps and are not working.

So if you ever want to go back from the current version to the previous 
one, you must go back several revisions without exacly knowing which one is 
the next working one (maybe it is possible to use tags to mark the working 
revisions but in my opinion this is to difficult, isn't it? And even with 
tagging you still have a lot of unnecessary revisions in the repository).

So my idea is to only commit correct changes to cvs. But the developer must 
still be able to check his changes on a webserver before commiting. The 
setup of the test webserver is complex and change often. So it is not 
reasonable to install such a webserver on each developer's box.

So I have the idea of sandboxes on a network share, one sandbox for each 
developer, but all sandboxes on a share on the test webserver. But this 
setup is not supported and I need a robust solution.

Hopefully I described my problem clearer now.

So what to do in this situation? Mabe I make things to complicate and there 
is a much easier solution.

Bye, Torsten

> We have been doing this for ages and it works really well.  The key steps
> are these:
>
> 1) Install the test web server on the CVSNT repository machine itself
> 2) Checkout a sandbox for the web server (don't point the web server
> directly at the repository files!) 3) Set up a replication scheme to keep
> the web server synced to the repository
>
> Until recently, we used CVSNTUPD.exe (a little utility I wrote) to keep
> the sandboxes in sync (with a delay of ~ 1 minute).  Now, with the
> massively cool postcommit option (Thanks Tony!), I have a little perl
> script which correctly updates the sandbox immediately.  The script is
> not really ready for public distribution (it's very ugly), but it works
> fine for us.
>
> HTH
>
> John

-- 
o __    innovativ partner
I l_)   office at ip-team.de
  l     www.ip-team.de
        02 31 / 14 20 57

_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt