Project distribution and DVCS

[Ben Finney]

Lester Caine <lester at lsces.co.uk> writes:

> I am still battling picking up the code and syncing with my own code,
> having wasted weeks trying to get git running on my set-up here.

Okay, I wasn't aware that you were having the usual acclimating issues
of using a new system. That, to my outsider's view, accounts for a lot
of your frustration.

> I don't as yet HAVE a working copy of a full 'superproject' for the
> code base, only parts, and they are not keeping in sync with the git
> repos.

This doesn't make much sense to me; you seem to be trying to keep VCS
repositories in sync when they're not using the same VCS system. That's
not something I would expect any tool to do well, so it doesn't seem a
good task to tackle if you're not yet familiar with the new tool.

> Things would be a lot easier if the existing keyword expansions
> were simply stripped from the source files - I'm mainly talking
> $header - since 95% of the 'diffs' I'm seeing are just changes in
> those lines when importing the third party stuff.

That seems to be the thrust of what many people in this thread's parent
have been saying: the automatic keyword-fiddling is at the core of the
problems you describe in that paragraph, and stripping them out would
avoid those problems altogether.

The information that used to be tracked in those keywords can simply go
into one or more separate files, tracked along with the rest of the
working tree. Since DVCSen track the tree as a whole, the information in
that file (e.g. a version string) is representative of the state of the
whole tree.

> The 'git archive' stuff that I've pulled in is just as messy, but I've
> not had at hg archive properly yet.

‘bzr export’, ‘hg archive’, and ‘git archive’ are explicitly *not* about
getting changes back in. If that's what you want, you've chosen the
wrong tool.

Perhaps you mean that people are providing ‘diff’ output? That's normal
and a good way to get changes from people not using your VCS. Each of
the major DVCSen provide a way to do that, to the extent that it can be
done at all.

But the problem of merging someone's arbitrary ‘diff’ is not peculiar to
DVCS; it's a main problem that's solved by VCS in the first place, by
having the other parties use the VCS. So perhaps I'm still not seeing
what the problem is and why you lay it at the feet of the VCS tool.

> The base problem is that I've been working with Eclipse/team for many
> years, and I'm simply used to seeing a list of files that have had
> changes. I can simply pull the commits, or 'bc' a file where I have
> local changes which I want to compare with other developers work.

I don't know those tools. But what you describe is what I see when I use
my VCS tool to merge someone's diff and inspect the resulting working
tree.

-- 
 \     “This world in arms is not spending money alone. It is spending |
  `\      the sweat of its laborers, the genius of its scientists, the |
_o__)           hopes of its children.” —Dwight Eisenhower, 1953-04-16 |
Ben Finney