On Jul 2, 6:18=A0pm, larwe <zwsdot...@gmail.com> wrote:

> Probably the single most frustrating thing for me in Tortoise is the
> way it lies about whether or not your local files match the remote
> copies. If the green icon doesn't unequivocally mean "your copy is
> guaranteed to be the same as HEAD" then the "feature" is a waste of
> time and shouldn't be there. This is an example of useless shell
> integration gone mad. A feature I can't trust is worse than one that
> isn't there.

Lewin, I fear that you completely misunderstand what the icons
represent. (NB: in the discussion below, I use the Subversion command-
line commands, which are generally the same as the TortoiseSVN context-
menu commands.) Reading the Subversion documents would be a good start
for you, as svn doesn't work like VSS.

When you see a green checkmark, it means that your local working copy
is unchanged from the revision you checked out of the repository.
Another user may have checked out, modified and committed changes to
the repo AFTER you checked out.

When you see a red exclamation point, it means that something in your
working copy has changed from the revision you checked out of the
repository. It shows that YOU changed something. It does NOT mean that
the repository has changed.

The icons are simply a visual indication of the "svn status" command.
If you were to go to the command line and run "svn status" in the
working copy, you'd see an "M" for all of the files that you modified.
This is all local working copy stuff and has nothing to do with what's
in the repository.

When you do an "svn commit," your changes are added to the repository
as a new revision and the head is bumped.

If you were to read the Subversion book, or perhaps the TortoiseSVN
help doc (which is pretty good), there's a discussion about general
Subversion usage. They point out that "typical" usage is as follows.
You check out a working copy, make your changes, and commit back to
the repo. Many developers keep "long-term" working copies, meaning
that you check out at the start of a project, and keep that same
working copy for the duration of the project. In this case, at the
start of your work day, you do an "svn update" to grab any changes
that your team may have made while you were asleep. "svn update"
silently merges their changes with yours.

Now if you go to commit changes and your working copy of "out of
date," meaning that someone else committed to the same trunk/branch,
you'll get the conflict notification, and you have to merge your
changes with what's in the repo. Tortoise Merge actually does a good
job with this, but you of course have to inspect each difference, and
make sure your changes and your colleague's don't conflict, and then
you commit the merged file back to the repo. Obviously, if you're used
to VSS where only one developer is allowed to modify a file at a time,
this can be scary and non-intuitive, but in practice, it's relatively
straightforward. (Merging branches back into the trunk is trickier and
it's worth creating a test repo/project to experiment and learn how
this works.)

Also, the Subversion book and docs also say that you should
communicate with your colleagues so that your changes don't bollix
theirs.

You can use Subversion for binary files, which are usually impossible
to diff and merge. You should implement locks for these files, which
basically makes Subversion work like VSS in that only one user can
grab a lock and modify a file.

Good luck. I think part of your problem is you're used to VSS and
Subversion is different.

-a

On Jun 30, 3:52=A0pm, larwe <zwsdot...@gmail.com> wrote:
> At work we're migrating from Source"Safe" to SVN. There is a strong
> focus on GUI-based tools for this, and the dev environment is Windows-
> only.
>
> I'm currently using TortoiseSVN which looks very pretty but is
> excruciating, frustrating and confusing in the extreme to use;
> absolutely nothing works the way you'd expect. Is there a simple-to-
> use Win32 SVN client that does NOT have shell integration, and that
> can:
>
> - look at the repository and compare two versions in the repository.
> (I still haven't worked out how to do this in Tortoise).
> - compare copy on my hard disk to repository HEAD.
> - check in, check out, lock, unlock.
> - merge capability is optional (we never use it, don't trust it).
>
> I basically want something that pops up two window panes, one showing
> the repository, one showing my hard drive.

Have a look at http://svnnotifier.tigris.org/
May this will assist. (Not with the panes, but at least with telling
you what / when something has changed
Rocky

Rocky wrote:
> On Jun 30, 3:52 pm, larwe <zwsdot...@gmail.com> wrote:
>> - look at the repository and compare two versions in the repository.
>> (I still haven't worked out how to do this in Tortoise).

"TortoiseSVN -> Show Log". Click and control-click the two versions you 
wish to compare, right click, "Compare revisions".

>> - compare copy on my hard disk to repository HEAD.

By golly, you haven't tried TortoiseSVN at all yet, have you?

"TortoiseSVN -> Diff", the very first thing on the menu.

TortoiseMerge is good and comes with TortoiseSVN. Many prefer WinMerge. 
Same price. Both have perfect integration with Tortoise. TortoiseSVN is 
polite enough during upgrades to recognize your selection of WinMerge 
and retain your choice.

>> - check in, check out, lock, unlock.

Read the SVN book. Locking and unlocking isn't as important in SVN as 
with other tools.

>> - merge capability is optional (we never use it, don't trust it).
>>
>> I basically want something that pops up two window panes, one showing
>> the repository, one showing my hard drive.
> 
> Have a look at http://svnnotifier.tigris.org/
> May this will assist. (Not with the panes, but at least with telling
> you what / when something has changed

How about "TortoiseSVN -> Check for modifications"? Whats so hard about 
that?

On 2008-07-07, David Kelly <n...@Yahoo.com> wrote:
> Rocky wrote:
>> On Jun 30, 3:52 pm, larwe <zwsdot...@gmail.com> wrote:
>>> - look at the repository and compare two versions in the repository.
>>> (I still haven't worked out how to do this in Tortoise).
>
> "TortoiseSVN -> Show Log". Click and control-click the two
> versions you wish to compare, right click, "Compare
> revisions".
>
>>> - compare copy on my hard disk to repository HEAD.
>
> By golly, you haven't tried TortoiseSVN at all yet, have you?
>
> "TortoiseSVN -> Diff", the very first thing on the menu.

By default, does that compare against HEAD or against the
revision that was checked out?

-- 
Grant Edwards                   grante             Yow! I'm totally DESPONDENT
                                  at               over the LIBYAN situation
                               visi.com            and the price of CHICKEN
                                                   ...

On Jul 7, 11:37=A0am, Grant Edwards <gra...@visi.com> wrote:
>
> > "TortoiseSVN -> Diff", the very first thing on the menu.
>
> By default, does that compare against HEAD or against the
> revision that was checked out?

It compares your working copy changes to the checked-out revision
which is actually stored on your hard disk in the .svn directory.

Now, if you right-click on a file in the Windows Explorer and choose
"TortoiseSVN->Show Log," the log messages history for that file will
appear. In the top window area, which shows all of the revisions, if
you right-click on a revision, you can diff any desired revision with
the working copy (select "compare with working copy"). Finally, if you
select a revision in the top window part (left-click), a list of
"actions" associated with that revision appear, usually in the form of
"modified" and a file path (in the repo). Right-click the "action" and
you can get a diff ("show changes").

I am convinced that anyone who doesn't think TortoiseSVN doesn't do
what they want to do simply hasn't spent enough time with it.

-a

In article <0ac4da47-170e-4522-888e-
8...@l42g2000hsc.googlegroups.com>, g...@latke.net says...
> On Jul 7, 11:37=A0am, Grant Edwards <gra...@visi.com> wrote:
> >
> > > "TortoiseSVN -> Diff", the very first thing on the menu.
> >
> > By default, does that compare against HEAD or against the
> > revision that was checked out?
>=20
> It compares your working copy changes to the checked-out revision
> which is actually stored on your hard disk in the .svn directory.
>=20
> Now, if you right-click on a file in the Windows Explorer and choose
> "TortoiseSVN->Show Log," the log messages history for that file will
> appear. In the top window area, which shows all of the revisions, if
> you right-click on a revision, you can diff any desired revision with
> the working copy (select "compare with working copy"). Finally, if you
> select a revision in the top window part (left-click), a list of
> "actions" associated with that revision appear, usually in the form of
> "modified" and a file path (in the repo). Right-click the "action" and
> you can get a diff ("show changes").
>=20
> I am convinced that anyone who doesn't think TortoiseSVN doesn't do
> what they want to do simply hasn't spent enough time with it.
>=20

I'd be happier with Tortoise if I could figure out (and fix) the=20
problem that seems to make my shared folders read-only.   It
wasn't a problem before Tortoise, but now I have to reboot frequently to
be able to move and delete files on shared folders.  Windows=20
shared folders are an essential part of the way I use the
3 XP PCs and laptops and the linux box on the local network.
Until I understand what is going on, Tortoise will be confined
to the single PC where it now resides.

On a happier note, I've got UBUNTU linux running in VirtualBox
on the PC  that has  all the source files.  Now I don't have to use
the Linux box to compile the GCC-Arm programs that were
it's raison-d'etre for the last year.  With a little more work,
I may be able to leave the linux laptop at home and only take
one WinXp laptop with VirtualBox when I travel.

Mark Borgerson



Mark Borgerson

"Mark Borgerson" <m...@comcast.net> wrote in message 
news:M...@newsgroups.comcast.net...
I'd be happier with Tortoise if I could figure out (and fix) the
problem that seems to make my shared folders read-only.   It
wasn't a problem before Tortoise, but now I have to reboot frequently to
be able to move and delete files on shared folders.  Windows
shared folders are an essential part of the way I use the
3 XP PCs and laptops and the linux box on the local network.
Until I understand what is going on, Tortoise will be confined
to the single PC where it now resides.

========
Procexp from sysinternals (www.sysinternals.com) will tell you which process 
has the file open. It would be surprising to find it was Tortoise hosing you 
over. I often rename whole sub-trees to make a quick branch.

[apologies for the late followup]

larwe <z...@gmail.com> writes:

> Probably the single most frustrating thing for me in Tortoise is the
> way it lies about whether or not your local files match the remote
> copies.

It doesn't lie, but you may be confused about what it is claiming.

> If the green icon doesn't unequivocally mean "your copy is
> guaranteed to be the same as HEAD" then the "feature" is a waste of
> time and shouldn't be there.

The green icon, IIRC, unequivocally means "your copy is guaranteed to
be the same as revision X", where X is the most recent revision to
which you have Updated.

At a PPOE, after our dev team had moved from CVS to SVN, I educated
our couple of Marketing folks in the use of Tortoise to update our
website, including creation of new tags so a cron job on the webserver
could auto-sync the latest "approved" tagged version.

mlp