Re: [vhdl-200x] Code sharing options

Martin,
Sounds great. I never used git, so I am not aware of the "local check-in"
feature, and a whole lot of other useful features you just mentioned.
The client-side merging capabilities sound really good to have; I especially
like this one:
"It's just a different workflow - instead of pushing changes to a server,
you email out a patchset and those who want it can merge it into theirs"

I personally should try git one of these days. Thanks :)

Regards,
Daniel

On Wed, May 4, 2011 at 4:08 PM, Martin.J Thompson <Martin.J.Thompson@trw.com
> wrote:

> >>> On 03 May 2011 at 19:01, in message
> <BANLkTinUNrWqjr04__VFcWxA9vvz9FvpSQ@mail.gmail.com>, Daniel Kho
> <daniel.kho@gmail.com> wrote:
> > Hi Martin,
> > Add one more (I think this is also distributed, after reading your
> > description):
>
> It isn't, see below. Sorry!
>
> > * TortoiseSVN
>
> There are TortoiseXYZ clients for almost all the systems I mentioned
> (Mercurial, Bazaar and Git certainly). They all provide much the same level
> of Windows Explorer integration, so i don't think is an issue for any of the
> systems.
>
> I think there's some confusion over the term "distributed". It means the
> *whole* repository is local to the user. Checkins can be done locally. You
> can pull other peoples changes directly from their repository. And you can
> push changes to a server from which others can pull (but this is *not*
> required necessarily)
>
> Subversion is not (currently, although there is talk of it) a distributed
> system. Subversion also has a number of other downsides that make me shy
> away from it (despite using it an awful lot).
>
> My experience of its merging capabilities is pretty bad (I resorted to an
> external tool) although it has apparently improved over the years, I still
> don't think it is up to the level of Git/Bzr (IMHO). Branching and merging
> is absolutely key for a distributed development programme.
>
> Subversion can be slow compared to the other systems.
>
> Finally, it keeps all your "last version" files locally (which is OK), but
> uncompressed and in plain text within a .svn folder within *each* of your
> folders in the source tree. This means that your source tree is twice as
> big as it needs to be. More importantly when you do a search (in explorer,
> or with "find" or a recursive grep for example) you get hits within all your
> source files *and* all the .svn folders (unless you take pains to remove
> them).
>
> The other systems keep a very compressed *entire* repository in a ".git"
> ".bzr", etc folder in one place in your project tree.
>
> >
> > TortoiseSVN is a client-side software (and it's free, as in beer). At the
> > server side, I'm not quite sure, but my guess is that they can use
> > Subversion (or any Subversion-like) repository.
>
> Well, yes, you have to use Subversion. No guessing - that's all there is
> to it.
>
> > It also has some of the
> > features you mentioned (Windows Explorer integration, automatic merging,
> > diff, etc.). When a client checks out a project, he/she will have a copy
> of
> > the repository on his local drive
>
> No, they have a copy of the last revision only. Not the whole repo with
> *all* its history and branches and everything else.
>
> > and can make as many number of changes
> > before he becomes satisfied to check his changes back to the main
> > repository.
>
> This is *not* the same is distributed version control. For example, with
> SVN you *cannot* "check in" locally, you must check in to the server.
>
> >
> > I guess there are other good Subversion clients (other than TortoiseSVN),
> > and hopefully, they too provide distributed computing.
> >
>
> Lets split clients and servers:
>
> There are TortoiseGit, TortoiseBzr, TortoiseHG, clients to make all the
> systems easy to use. And there are other Subversion clients (will still be
> for subversion and hence not distributed)
> Subversion (and hence TortoiseSVN) is not currently a distributed system
> (their tag line is "Enterprise-class *centralized* version control for the
> masses" - my emphasis.)
>
> > "* Platforms:
> > - Is good Windows support important?
> > - Is good Mac support important?
> > - Is good Linux (other Unix?) support important?"
> > To me (my own personal opinion), at least good Unix and Windows support
> will
> > be great. If we choose one distributed solution that also has a central
> > server (like Git or Subversion/TortoiseSVN), the server can be Unix,
> while
> > the clients can either be Unix, Windows, or Linux (or even Mac).
>
> OK, I was really thinking entirely of client support there - assuming we
> use an external provider of servers, it's not a problem what it runs on !
>
> >
> >
> >
> > "Alternatively:
> > * we could set up our own server.
> > * we could just all have our own local repositories and pull changes from
> > each other (the Linux kernel is developed like this)."
> > Actually I like this idea. But that's because I have a homeserver (just a
> > laptop actually) running on OpenSolaris, which uses the ZFS filesystem
> (and
> > can pull changes from each other just like a version control system).
> > However, there may be others who may only have Windows. I guess we need
> to
> > think about them as well.
>
> No server is required. It all runs locally, (using the Tortoise* tools on
> Windows), Windows users will be fine. It's just a different workflow -
> instead of pushing changes to a server, you email out a patchset and those
> who want it can merge it into theirs
>
> Cheers,
> Martin
> --
>
> Martin Thompson CEng MIET
> TRW Conekt, Stratford Road, Solihull, B90 4GW. UK
> +44 (0)121-627-3569 : martin.j.thompson@trw.com
> http://www.conekt.co.uk/
>
> Conekt is a trading division of TRW Limited
> Registered in England, No. 872948
> Registered Office Address: Stratford Road, Solihull B90 4AX
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.