>------- Additional comments from sussman@tigris.org Thu Oct 16 07:07:21 -0700 2003 -------
>Brandon, I ask that you think this enhancement through: suppose you create a
>file foo.c, and it's unversioned. Then you run 'svn up --ignore-obstructed',
>and the repository adds a versioned foo.c (i.e. to the entries file, and to
>.svn/text-base/). Now it looks like you have a giant local mod -- when you run
>'svn diff', it appears that you've completely gutted the old file and added the
>new text instead. Is that good?
>
>Or suppose you have your own 'foo.c' scheduled for addition, and run 'svn up
>--ignore-obstructed' which tries to add an existing foo.c from the repository.
>How should we behave in that case? Convert the schedule-addition into a
>schedule-replace?
>
>Or suppose you have foo.c under version control already, and make some local
>mods to it. But then 'svn up' wants to delete the file. Normally, this causes
>an obstructed update, to prevent accidental data loss. If you
>--ignore-obstructed, should it just delete the file from the entries-file anyway
>and leave the file unversioned? This was the old behavior, and it ended up
>biting a bunch of people, who didn't realize the file became unversioned.
>
>'svn up' is a powerful thing... it's a real tree-merge between your working copy
>and the repository. Obstructed updates aren't trivial little errors meant to
>annoy you during an update -- "bah, just update anyway". They're giant red-flag
>errors indicating conflicts -- tree conflicts, rather than textual conflicts --
>but there's *just* as important as text conflicts. I wouldn't want a flag to
>ignore text conflicts, so I'm not so sure it's wise to allow people to ignore
>tree conflicts either. A '--ignore-obstructed' flag makes it too easy for
>people to say "let the software resolve the tree conflict for me", while not
>understanding the exact way in which the software will behave in each edge case.
> It's like a giant noose.
>
>
The number one reason that the company I work for would absolutely
require this behavior is because they've worked on a version control
system that previously didn't support this, and the new one currently
does. While I agree that your average CVS user would probably never
need this feature, the artists on this team who are managing hundreds of
binary files would go on strike if we forced them to live without it.
The biggest problem that this creates is if you are storing lots of
binaries in the repository and they are created via some sort of tool
that generates lots of files. Artist Alex starts some initial work in
the tool on one section of and fills up his working copy with these
generated binaries. Artist Bob does the same thing, but because he's
working in a different area but with the same tool, it generates lots of
the same binaries. Alex then checks his stuff into the repository, and
he checks in all the files that he are modified on his machine, which is
a good thing because people might need to use those assets right away
before Bob has a chance to check in. Bob then goes to update, but his
update fails because of an obstructed file.
In the current Subversion model, Bob would have to resolve this issue by:
1) Run svn up.
2) Delete or Backup the file in question.
3) Run svn up.
4) Optionally copy his file back over the original if its the one he
wants to replace.
5) Repeat steps 1 through 4 about 100 times.
As you can see, that doesn't make for very happy artists.
There are a couple things wrong with this model:
* Bob can't see the full list of obstructed files, because he would have
to repeat step 2 writing down every file that he moved.
* Bob knows more about the relationship of the files being stored than
the repository, but cannot exercise this knowledge.
* Artist Carl might need some help from Bob before Bob is finished his
current stuff. If Carl's stuff is in the same directory there is a
50/50 chance that Bob will be able to pull Carl's stuff from the
repository depending on the order that the files are retrieved via svn up.
* Bob may not be ready to accept Alex's changes yet, but he needs some
changes from Carl in order to finish. Again there is a 50/50 chance
that he can bring down Alex's changes successfully. If Subversion hits
the obstructed update first, Bob will either need to find all of Carl's
100 files and update them manually, or he will need to repeat steps 1
through 5 from above, and after he's finished, put all of his files back
over top of Alex's files and write down the name of every file that was
obstructed so that he can move his files out of the way again and grab
Alex's files and then replace any of Alex's files with his own before he
can commit.
These are just some of the cases that our Artists run into on a daily
basis that make obstructed updates painful. We definitely still want
svn up to return an error every time Bob updates until he resolves all
the obstructed files, but it needn't be quite so painful as it currently
is. I'm not exactly sure what the behavior of --ignore-obstructed
should be, but currently for us it remembers the files that are
obstructed and all operations on those files fail until Bob either moves
the file in question out of the way or tells the repository that his is
the correct version.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 16 20:43:29 2003