> > what I always hated with VCC based sourcecontrol
> packages was:
> > - they make files readonly on disk
> > - they pollute vs.net project and solution files with
> garbage which will cause havok when you open it on another system.
> >
> > Does TFS also lock files on disk and pollute your solution
> > files with VCC crap? Or is that optional and can they also
> do the edit/checkin pattern?
>
> The files are read-only on disk so that you don't fiddle with
> them without "pending a change".
I don't get this. A change locally isn't a change in the central
storage, which is the _only_ reality. The local copy is
just a copy. As long as you don't try to check it in, nothing is done to the
real situation in the central storage. This is the same
with SVN for example: if you edit locally and then commit and someone else
already made a commit after your last update, you'll get
an error and you have to update your local copy first.
Making files readonly is also silly: it doesn't prevent anything (you
can make the file non-readonly with a simple command)
yet it is annoying when you want to alter some files.
> This does NOT lock the
> file, just notifies TFS that the specific version that you
> have "previously gotten" has a possible pending change.
> Later, when you commit everything it knows what files to
> examine (not based on the read-only bit being off, but based
> on the notification it got). This means that HUGE directory
> trees are not scanned for check-in, rather the possible set
> of files is known.This does mean that you could (outside
> whatever too, be it the IDE integration or the command-line
> stuff) clear the read-only bit and fiddle the file and it
> would never get checked. This is mitigated by occasionally
> doing a get-latest which will detect the files has been
> touched, pend a change and ask you to merge (or do so
> automatically). This is also how offline changes are handled (i.e.
> when the TFS server is inaccessible).
odd, as SVN is able to get this change and will commit it. As long as
the folder / file is in the repository of course. But
if it isn't, it's not part of the reality in the central storage so nothing has
to be checked anyway.
> As for the cycle, this is VERY close to the edit/merge/commit
> model of SVN, except you always are assumed to be commiting
> against the the verion that you pended the edit against.
that's also true for SVN: you can't commit to revision 10 (your
version) if you do a commit against HEAD and the HEAD is
revision 11.
> This means that if someone else did changes after you pended
> your edit, you get the option to merge or branch then. The
> locks are optional (you can request that nobody can pend
> edits, or you can request that nobody can check-in, OR you
> can request no lock at all). There are some REALLY great
> blogs about this, start with Buck Hodges' at
> http://blogs.msdn.com/buckh
thanks, I'll check them out :)
> The latest cool feature is that you can do baseless merges,
> which is where you and I are working on two project and sharing a (say
> third-party) library. After a while, we both realize that the
> other is using that library and making changes... we can tell
> TFS that they both are the same and it lets us merge them
> EVEN in the absence of a common root version. Once that
> happens, the delta are maintain against the common trunk
> chosen at the baseless-merge time. It's awesome.
something like the switch command in SVN, so one of the persons in the
example uses switch to switch over to the folder of
hte other for that folder?
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
