[cvsnt] Re: Best practices for shadow sandbox

John J. Xenakis mhare at jxenakis.com
Mon Jan 2 23:45:05 GMT 2006


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


Dear Gerhard,

>   Did you run a Google search on "best practices" (quoted) and cvs?
>   It comes up with quite a number of links that look like they have
>   something to say. Maybe no "best practices bible" around, but
>   that's probably because the environments (development, team,
>   administration, IT) are so different.

Thank you for that suggestion.  I tried it and got interesting
results.  Most of the entries seem to refer to best practices for
things like branching and merging, especially in a paper by
Vivek Venugopalan.  I'll study that stuff when I get to it, but right
now I'm mostly looking at basic UI issues.

>   It's not as "round" as some commercial solutions. But that's not
>   exactly the same as "shoddy" (in my book, at least :)

I agree completely!  I'm just saying that if the product is poorly
configured, then the product gets blamed, rather than the
configuration.

>   IMO you need to find out what exactly you need, and this depends a
>   lot on the specific environment. Then you have to set up a set of
>   "best practices" using the available tools. For some environments,
>   cvs(nt) is probably not a good match, and other choices may be
>   easier to implement. But it's not a question of any of the tools
>   "addressing" a fixed set of best practices -- the question is how
>   you can address your requirements with the available tools. The
>   cvsnt and the cvs manual are good starting points for this.

>   Note also that TortoiseCVS and WinCvs are not the only client-side
>   tools that are available. There are a number of other clients,
>   some shells around cvs.exe, others with their own client
>   implementation. There are also tools that implement the Microsoft
>   SourceSafe SCC interface (one that I'm using is from PushOK
>   Software).

For the first pass, I'm assuming that "exactly what I need" is
something similar to Visual SourceSafe.  I'll check out the PushOK
product.


>   Whether what VSS enforces or encourages are really "best"
>   practices is really a matter of opinion (and don't be surprised if
>   most here don't share your opinion about this being "best"
>   practices :)

I understand your point, especially as regards the functionality of
the repository.  I'm referring to user interface kinds of things.

>   CVS has been designed by developers for developers, basically.
>   There's not really the "naive user" in this environment. It has
>   grown since then, and some of the client tools, together with a
>   good set of rules (or "best practices") and a capable support, can
>   go quite a ways to make this work for the naive user. I use it
>   here around the house with "naive users" quite successfully, using
>   shell scripts.

I understand this, and I've only used it in software development
environments myself, before now.  I recommended it thinking that my
client's "naive users" would only use a small subset of the
functionality anyway -- checking DOC files in and out -- and I felt
that this should be easy to do using CVSNT.  I've been surprised by
how difficult it's been to get all this set up, but I'm beginning to
see the light at the end of the tunnel!

>   It's always difficult to mimic the working of one tool with
>   another one. You often end up with something that's not as good as
>   the one it's mimicking, but underutilizing the added benefits of
>   the used tool (because they are not part of what is supposed to be
>   mimicked).

Mimicking VSS was not really a requirement, but it was a starting
point.  I felt that if I could configure CVS to do the simple VSS
functions in a way that naive users could understand, then I could
get past any other problems.  As I said, it's turning out to be
harder than I thought, but hopefully I'm getting there.

>   You could look at what it means when a file is marked as "binary".
>   It basically means two things:

>   1- End-Of-Line characters get not translated between different
>   client operating systems. For text files, you get the correct line
>   terminations, no matter whether you check out the files on a Unix
>   type or Windows operating system.

>   2- Files don't get merged by cvs. (That's where the usual
>   requirement comes from to work only on the last revision.)

>   If you want to enforce exclusive edits, one possibility is to add
>   these files as binary -- if you can live with the above two
>   consequences. This has the advantage to be compatible with pretty
>   much all cvs client tools, as all of them recognize binary files.

>   You can set up a server-side cvswrapper file that contains entries
>   for the various file types and forces them as binary files.

I understand all these distinctions, and I've been playing with the
cvswrapper file to do what I want, but I haven't been able to get it
to work.

>   AFAIK you can also specify the -kx option there. The possible
>   disadvantage with this is that some of the client tools may not be
>   aware of this option. For example, I don't know whether Tortoise
>   does the automatic update-before-edit on -kx files (like it does
>   on -kb files).

I don't follow this.  There's a -kx option for "cvs edit" which
guarantees exclusive use, but as you say, Tortoise doesn't appear to
use it.  And there's the -kb option for "cvs add", which specifies
binary.  Is that what you mean?


> There's one more serious usability problem that perhaps you could
> comment on -- the "client view" rather than the "server view." 
> 
> This seems like a relatively small thing, but it appears to have major
> consequences. 
> 
> In Microsoft Visual SourceSafe you can browse the entire directory
> structure on the server.  Once you've set up your working directory
> (sandbox directory), you can selectively "get" or "checkout" one, two
> three files, or an entire sub-directory, or the entire project. 
> 
> But on CVSNT you can't do any of that stuff, as far as I can tell.  

>   Yes, you can. The "cvs ls" command gives you the basics, and there
>   are a number of client-side tools that provide you with a "server
>   side" GUI view of the repository. The cvsnt Workspace Viewer is
>   one (it comes with a very limited functionality in the open source
>   version, but I'm told that the paid version can do more). Other
>   client tools, like for example SmartCVS, implement something
>   similar.

Thanks for the suggestions.  This will become an increasingly bigger
problem as the number of files increases.

Sincerely,

John

John J. Xenakis
Xenakis Consulting Services Inc.
44 Dinsmore Ave #304
Framingham, MA 01702
Phone: 508-875-4266
E-mail: john at jxenakis.com
http://www.jxenakis.com

a.b



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook